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

[Mike Hearn]

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/87fc77a4/attachment.htm>