Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Ron Pressler]

> On 6 Sep 2023, at 11:57, Simon Nash <simon at cjnash.com> wrote:
> 
> Thank you for this constructive response. My application is used to play audio files, so the users are people who like listening to music and generally know very little about software and probably nothing about Java, JNI. native methods, etc.
> 
> This application is packaged as a set of jar files and a native library accessed using JNI. It supports a wide variety of deployment platforms including Linux, Windows, macOS and various NAS platforms. On some NAS platforms it is packaged with a tailored Java runtime but on most platforms it uses the JDK or JRE that the user has installed on the platform, which can be any version from Java 8 onwards.

Why? You can now easily pick whichever runtime you want (a minimal one is only 40MB!) and not require the end user to install Java or even know that your application is written in Java. Also, the proposed change would have no impact on anyone using a client JRE (8 is the *highest* version for which a JRE is available).

If you opt not to choose the runtime and the user updates the runtime, the warning will correctly indicate that the application will need to be updated in order to run on future runtimes.

So you have two options:

1. You let someone else take the responsibility of choosing a runtime for your application, in which case, as those who are responsible for providing the runtime, they need to be warned that providing some future runtime may cause the current.

2. You choose to be responsible for providing the runtime, in which case you control every aspect.

I think these are both reasonable options. A third option is for us never to evolve the platforms in ways that we think are necessary to adapt to new requirements, and I think this option is significantly worse than the other two.

> 
> Backward and forward compatibilty are very important for the application, so new versions of the application must run on all versions of Java back to Java 8 and older versions of the application should continue to run when the user updates the JDK version on their Linux, Windows or macOS system.
> 
> The scenario that causes this issue is where a user is running version N of the application on a Linux, Windows or macOS system with JDK 21 or earlier installed and then updates to JDK 22 or later. They will now see scary warnings that they did not see previously. By this time, I will have released version N+1 with the new launcher jar attribute to suppress the scary warnings but there is nothing in the warnings that informs the user about this, just a lot of technical jargon that they don't understand and suggests that the application is doing something bad.

Right, and because we deprecate and remove features from time to time and because some libraries have used undocumented JDK internals that aren’t subject to any compatibility promise, in practice Java never had perfect compatibility. So we’ve worked hard to deliver a solution that will give any application very precise control over the runtime. Obviously, if you choose not to use the solution to the problem the problem persists, so I’d like to understand why.

— Ron