<div dir="ltr">Hello all,<br><br>As a lead developer on Quarkus, I’ve been following Leyden closely and collaborating with our team (Andrew Dinn, Andrew Haley, Ashutosh, Maria, et al.) on its implications for Java. I intend to get into the habit of sharing feedback here directly more often.<br><br>I prefer Vladimir's initial proposal, as it favors the "first impression" and provides better defaults for the audience least likely to tune their settings. Most developers will first evaluate Leyden on a single machine or identical hardware. If we restrict out-of-the-box benefits to avoid edge-case hardware mismatches, we risk a "lukewarm" initial experience. The edge-case you'd be addressing isn't a critical failure. Java should feel fast by default; we shouldn't penalize the 90% to protect the 10% who are already equipped to handle configuration.<br><br>In Quarkus, we intend to ship container images with preloaded AOT archives.This implies I should be advocating for the opposite as we’ll need portability, but as an image maintainer, I expect to customize the bootstrap with ad-hoc parameters better fitting our intent, and anyone shipping a specialized end-user product will exercise that same discretion. So this won't at all be be a problem for us.<br><br>Finally, I’d like to stress the importance of the JVM maintaining its edge when compared to GCC/LLVM-compiled alternatives. We spend enough time debunking the myth that Java is slow; the JVM needs to demonstrate its peak performance potential to individuals who may not be aware of its full capabilities.<br><br>Large-scale users with heterogeneous cloud environments might need different settings, but they have both the resources and the motivation to implement staging environments in which such problems will be caught, and aren't going to be intimidated by the need to set any new flag.Let’s keep the entry barrier low for everyone else.<br><br>Thanks,<br>Sanne<br><br>On Mon, Jan 26, 2026 at 11:24 AM Andrew Haley <<a href="mailto:aph-open@littlepinkcloud.com">aph-open@littlepinkcloud.com</a>> wrote:<br>><br>> On 26/01/2026 09:38, Severin Gehwolf wrote:<br>> > IMHO, the default should be "generic".<br>><br>> While I (slightly) agree with you about the default, as long as the<br>> options are easy to select with a single command-line argument, it might<br>> not matter very much in practice.<br>><br>>  > Consider that they could run into the trap<br>>  > of thinking they'd get a good boost, but then are disappointed on the<br>>  > production run because the AOT code cache cannot be used and is being<br>>  > thrown away. The user walks away being disappointed and might only ><br>>  > > come back trying the feature with a later JDK release.<br>><br>> That's a good point, well made. I'd say something radical: don't have a<br>> default, but force the user to choose. They'd get used to that wuickly<br>> enough.<br>><br>> Andrew.<br>><br>><br></div>