<div dir="ltr">I am very aware of what is being changed here; I know that JNI will still be around, and be usable. However, the restrictions that are going to be imposed on using it won't exactly make it easier to use, and require even more boilerplate setup for an end user to set up an app or library. I know that launchers exist, and I know that the manifest can also permit the usage of JNI, but if it would solve the issue, I wouldn't be here talking about it. The issue at hand is that the usage of JNI in the future will require the end user of a library to either make a startup script (which is not always the default procedure for smaller applications), or to add another entry to their manifest, both options often require a bit of rethinking about how they should build their project. It's not an easy solution, and it certainly makes things more annoying if a library just wants to use some more advanced features.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 28. Aug. 2023 um 18:39 Uhr schrieb Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think you have a serious misunderstanding of what is being proposed <br>
here.  Nobody is taking away JNI.  What is being taken away is the <br>
ability to bury the use of JNI in a library where the user is unaware of <br>
it.  By "user" here, I mean the person putting together a Java <br>
application from a group of modules and JARs -- sometimes called the <br>
"application assembler."  This user has a right to know what their <br>
application is doing.<br>
<br>
When we started to enforce the accessibility model in Java 9, we didn't <br>
take away the ability to do deep reflection, we took away the ability to <br>
do so _without the user knowing_.  The reason that the various <br>
`--add-opens` are specified on the command line is so that the user has <br>
a chance to consent to relaxed integrity.  JNI is the same; we're not <br>
taking it away, but we're helping the user be aware of when a library is <br>
putting the integrity of the application at risk, so that they have the <br>
ability to make a judgement call on whether they are willing to trust <br>
that library.<br>
<br>
<br>
On 8/28/2023 11:37 AM, Constantin Christoph wrote:<br>
><br>
> JNI is a fundamental part of the java ecosystem, and it shouldn't be <br>
> restricted in a manner like this. It's a powerful, useful tool, and <br>
> should be treated like that. Developers should have that option freely <br>
> available.<br>
<br>
</blockquote></div>