Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI
Simon Nash
simon at cjnash.com
Wed Sep 6 10:57:10 UTC 2023
On 05/09/2023 12:38, Ron Pressler wrote
>> On 5 Sep 2023, at 10:55, Simon Nash <simon at cjnash.com> wrote:
>> As I explained in an earlier message, I can release a new version of my application that has this change (I will use the new attribute in the launcher jar) but many users are still using older versions of the application without this change. They will see the scary warning and will not know what they need to do to make it go away.
>>
>>
>> They will only see a warning if they configure the old version of your application to use a new Java runtime that they themselves provide. If they are developers who know how to use the JDK and configure its launcher to run your application, then why would they be scared? If they’re not developers, how would they obtain a new version of the Java runtime and configure your application to use it?
>>
>> I’m trying to understand how such a situation could arise and what kind of users we’re talking about.
>>
>> — Ron
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.
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.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230906/a588d8d9/attachment.htm>
More information about the jdk-dev
mailing list