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

[Gregg Wonderly]

> On May 17, 2023, at 4:33 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> But keep in mind that since Java has shifted away from the JRE model, self-contained Java applications are encouraged to use jlink to embed their own runtime and pick their arbitrary command-line options rather than rely on executable JARs and require the user to have a pre-installed Java runtime.

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 in a new, version appropriate jar file such that  a Java ”upgrade" doesn’t break the use of that application. This is the primary issue with a dynamically compiled runtime environment. Forward compatibility is hard. Backward compatibility harder.

Java runtime configurability needs to use a runtime accessible class that is initially configured by the manifest.  It should then provide the ability for the user to further “configure” compatibility as they need to into something like Preferences or some other mechanism.  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.  Today, if a runtime error occurs on a double clicked application, there is nothing that tells the user anything.  There appears to be nothing happening.  They have to go to a command line and type “java -jar file.jar” to see errors.  It’s all of these kinds of thing that new command line requirements to fix “risks” need to be sure and manage effectively.

Gregg