[External] : Re: New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

[Ron Pressler]

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 <mike at 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.pressler at oracle.com> wrote:
> 
> 
> > On 17 May 2023, at 23:01, Gregg Wonderly <greggwon at 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
>