<div dir="ltr">The JDK <i>allows</i> bundling a JVM since 9 and makes it <i>possible</i> since about 15 (jpackage), but still doesn't make it <i>easy</i> like throwing a JAR around was easy. Although you discuss market demand here, the market isn't really united on what it wants in this case.<div><br></div><div>Eliminating deployment complexity is often a reason for the success of "worse is better" approaches, because deployment is a frequent blind spot for platform vendors and when it does get addressed it's via extractive stores that create as many problems as they solve:<br><div><div><ul><li>Clickable-uberjar was a common way to deploy java apps</li><li>Go users say they really like the single binary output</li><li>GraalVM native image has seen success partly for the same reasons</li><li>Every language has a bunch of "bundle it up into one file" tools, JS got another one just last week in fact!</li></ul><div>There's also some close equivalents:</div><ul><li>Gradle and Maven now use wrapper scripts that let you deploy build systems as if they were a single file.</li><li>Docker is <i>not</i> single file but took over the world because it gives you tools for working with apps as if they are.</li><li>NeXT/macOS bundles let you work with apps as if they are single files.</li><li>Web apps have historically often been pushed by devs even when the UX is worse (higher latency etc) because browsers do a good job of deployment. You don't even need a single file, just a URL!</li></ul><div>These are huge industry trends and they're all about simplification of deployment at the cost of almost everything else (security, build time, performance etc). Deployment pain <i>really</i> matters to people to an extraordinary degree and way more than it's ever given credit for.</div></div><div><br></div><div>The question was asked, in what situations don't you control the CLI of an app? Gregg provides an answer: people who were happy with the old JRE model and still use it. He doesn't seem to be interested in jlink/jpackage, which is fair, because they either requires you to build and maintain platform specific signed packages (pain for the developer) and/or for users to master unzipping of things and management of folder hierarchies and executing unsigned native code (pain for the user). They don't let you work with apps as if they are single files, in other words. He was happy with sending users a portable JAR that does some self-extraction and self-updating tricks using nice high level APIs like URLClassLoader, because that was easy! Sun/Oracle endured the pain of deploying and updating the native runtime.</div><div><br></div><div>Now, the modern OpenJDK project doesn't want to do that anymore. That's fine; a perfectly understandable business decision. My company takes on the pain nowadays, <i>but</i> it's still ultimately in that electron/flutter/jlink model of bundling a runtime <a class="gmail_plusreply" id="plusReplyChip-0">+</a> making platform specific packages. Our product bends over backwards to make it easy for people compared to the JDK tools, but compared to slinging JARs it's still in some ways worse: we charge money, the files it makes are way bigger, you need to buy signing keys or publish via the MS Store, the build process is slower, and so on. The consolation prize is that you get more features.</div><div><br></div><div>Still, if self-updating fat JARs worked 95% well enough for you whether on desktop or server, then you're going to fight against the Jigsaw+jlink model all the way and it's probably rational to do so. Having other people deploy a nice modern runtime for you is just so convenient.</div><div><br></div><div><br><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 18, 2023 at 1:02 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 17 May 2023, at 23:01, Gregg Wonderly <<a href="mailto:greggwon@cox.net" target="_blank">greggwon@cox.net</a>> wrote:<br>
> <br>
> Again, the supposition here, is that somehow anyone who once built an application into a jar file that is in use today, can somehow cause a release of a new version of the JDK that appears in a user’s environment, to correlate with getting a new, compatible version of the application<br>
<br>
Not only is this — controlling the runtime environment and its interaction with the application — exactly what the JDK has allowed standalone applications to do since JDK 9, but also what we’ve encouraged them to do.<br>
<br>
> There really needs to be a way that the Java version for an application can be specifically designated and that version discovered and made available to the user through a reasonably informative mechanism.<br>
<br>
Are you not aware that this was addressed nearly five years ago? Actually, Java does better than this. It no longer requires you to depend in any way on some separately installed Java runtime on the user’s machine. The user need not even be aware that the application is written in Java.<br>
<br>
— Ron<br>
<br>
</blockquote></div>