Right, for agent loading it probably doesn't matter. I think the reaction is to the general direction of travel. Panama also requires a command line flag, JNI may do so in future, maybe other features. The latter would cause any fat jar app that does self-extraction of native code to break. That's still pretty common to see in little CLI tools or GUI demos distributed on github, for example. Having a JVM-Flags manifest entry would also fix that. Alternatively, bringing back a WebStart like mechanism could also work.
I agree jlink is a more powerful approach. The question is whether there's a path that tips the cost/benefit trade-off back in the direction of convenience, without losing the upsides. On Thu, May 18, 2023 at 2:29 PM Ron Pressler <ron.press...@oracle.com> wrote: > Just to be clear, the abilities of executable JARs have not been limited > in recent years any more than they had been before. When JEP 261 added the > --add-exports and --add-opens options and disabled self-attach it also > added the Add-Opens, Add-Exports, and Launcher-Agent-Class manifest > attributes. The issue of control over the command line is largely > irrelevant for executable JARs because it pertains to controlling > capabilities they’ve never had (and/or virtually never need), anyway. > > It’s just that jlink has allowed standalone Java applications to go beyond > what executable JARs have been able to do, and addressed problems that > executable JARs have always had. So if the question is why is future work > focused on jlink rather than executable JARs, the answer is that executable > JARs suffer from some fundamental limitations that only something like > jlink can address (sure, there are tradeoffs involved, but they apply to > all of your examples). The ease and power of the jlink model is expected to > significantly improve further by Project Leyden and work adjacent to it — > stay tuned! > > As far as this JEP (451) is concerned, it is highly unlikely that the user > of an executable-JAR application has both the ability and need to attach a > serviceability agent for deep troubleshooting beyond what’s possible > without dynamically loaded agents (especially with no access to the > sources), but if they do then surely they’re also able to add the > -XX:+EnableDynamicAgentLoading flag. > > — Ron > > > On 18 May 2023, at 10:27, Mike Hearn <m...@plan99.net> wrote: > > > > The JDK allows bundling a JVM since 9 and makes it possible since about > 15 (jpackage), but still doesn't make it easy 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. > > > > 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: > > • Clickable-uberjar was a common way to deploy java apps > > • Go users say they really like the single binary output > > • GraalVM native image has seen success partly for the same reasons > > • Every language has a bunch of "bundle it up into one file" > tools, JS got another one just last week in fact! > > There's also some close equivalents: > > • Gradle and Maven now use wrapper scripts that let you deploy > build systems as if they were a single file. > > • Docker is not single file but took over the world because it > gives you tools for working with apps as if they are. > > • NeXT/macOS bundles let you work with apps as if they are single > files. > > • 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! > > 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 really matters to people to an > extraordinary degree and way more than it's ever given credit for. > > > > 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. > > > > 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, but it's still ultimately in that electron/flutter/jlink > model of bundling a runtime + 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. > > > > 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. > > > > > > > > > > On Thu, May 18, 2023 at 1:02 AM Ron Pressler <ron.press...@oracle.com> > wrote: > > > > > > > On 17 May 2023, at 23:01, Gregg Wonderly <gregg...@cox.net> wrote: > > > > > > 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 > > > > 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. > > > > > 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. > > > > 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. > > > > — Ron > > > >
