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

[Mike Hearn]

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.pressler at 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 <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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230518/1bf5e415/attachment.htm>