JEP draft: Prepare to Restrict The Use of JNI

[Brian Goetz]

I think you have a serious misunderstanding of what is being proposed 
here.  Nobody is taking away JNI.  What is being taken away is the 
ability to bury the use of JNI in a library where the user is unaware of 
it.  By "user" here, I mean the person putting together a Java 
application from a group of modules and JARs -- sometimes called the 
"application assembler."  This user has a right to know what their 
application is doing.

When we started to enforce the accessibility model in Java 9, we didn't 
take away the ability to do deep reflection, we took away the ability to 
do so _without the user knowing_.  The reason that the various 
`--add-opens` are specified on the command line is so that the user has 
a chance to consent to relaxed integrity.  JNI is the same; we're not 
taking it away, but we're helping the user be aware of when a library is 
putting the integrity of the application at risk, so that they have the 
ability to make a judgement call on whether they are willing to trust 
that library.


On 8/28/2023 11:37 AM, Constantin Christoph wrote:
>
> JNI is a fundamental part of the java ecosystem, and it shouldn't be 
> restricted in a manner like this. It's a powerful, useful tool, and 
> should be treated like that. Developers should have that option freely 
> available.