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

[Rony G. Flatscher]

On 04.09.2023 11:48, Ron Pressler wrote:
>> On 3 Sep 2023, at 21:14, Simon Nash <simon at cjnash.com> wrote:
>> You have not addressed my point that the end user of the application will see this scary warning when they are using a Java application that is doing nothing wrong (the application is just using a well written and well behaved JNI bridge to a well written and well behaved external C++ library).
>>
>> What is the end user of the application supposed to do when they see the following?
>> WARNING: A native method in org.baz.services.Controller has been bound
>> WARNING: Controller::getData in module org.baz has been called by com.foo.Server in an unnamed module
>> WARNING: Use --enable-native-access=org.baz to avoid a warning for native methods declared in org.baz
>> WARNING: Native methods will be blocked in a future release unless native access is enabled
>> The end user of my application doesn't know what a native method is or what --enable-native-access=org.baz means. They are being told to use --enable-native-access=org.baz but what can they do to obey this instruction? Only the developer of the application is able to make this change. The only thing the application end user can do is to stop using my application and use another similar application that is not written in Java and possibly even more dangerous but does not emit scary warning messages.
> The end user of your application need not see the warning at all. If you, as the application author, pick a runtime based on a JDK version that has this warning for your application, then *you*, as the application author, will pass the flag to the Java runtime. Your application’s end user need not know about any Java flags; they need not even know your application is a Java application. These are all internal details of your application.

Hmm, how about stepping back a few steps and look at what has been said on this thread repeatedly?

You - and your peer's - assumptions on how to take advantage of Java/OpenJDK seems to be restricted 
to monolithic Java applications and creating tailored runtime environments using jlink. Any other 
use of Java/OpenJDK has been ignored all over this thread which is very unfortunate.

In the case that Java/OpenJDK gets used as an infrastructure, as an available huge class library 
taken from the currently installed Java/OpenJDK *without* any process to create a monolithic Java 
application will cause that warning to be shown to end users or users who have no insights into 
Java/OpenJDK details.

It is that scenario that should be avoided by all means as it will make (end) users insecure using 
Java/OpenJDK, especially as Java/OpenJDK issues that warning. There is currently nothing that 
shelters those end-users from that frightening warning if I understand the current JEP correctly, 
eventually even inhibiting the execution of such non-Java applications in future versions of 
Java/OpenJDK.

If time permits, I will come up with a few use cases of Java/OpenJDK trying to make it 
understandable for the "monolithic Java application" people that there are other, important uses and 
interactions with Java/OpenJDK that the group you represent seems to not (want to) take into account.

Belittling any feedback that does not fit into the expectations and assumptions of the authors of 
the authors of the current JEP with that warning does nothing good for Java/OpenJDK, the 
fear/expectation (from experience not from speculation) is that it will harm Java/OpenJDK (and Java 
libraries instrumentating JNI) massively.

---rony