> On May 17, 2023, at 4:33 PM, Ron Pressler <ron.press...@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
