<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>I agree that some control should be given to the user, but definitely not the way it is now. </div><div><br></div><div>When I enable native access for a module, it can actually have native access in any way it wants.<br></div><div>If it wants to use JNA without the user knowing, it just needs to copy JNA into its module.<br></div><div>This is an implementation detail of it, and forcing the library to expose these details does </div><div>nothing positive and will only drive more users away from JPMS.<br></div><div><br></div><div>Whether as a library developer or as an application developer (your so-called "user"), </div><div>I hope to make "enable native access" more deeply integrated with the JPMS.<br></div><div><br></div><div>Here's what I want:<br></div><div><br></div></div></div></div></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>1. Allows a module to declare that it wants native access:</div><div><br></div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>```java</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>module org.glavo.mylib {</div><div> requires native; // Check for permissions when loading</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> // or</div><div> requires static native; // Check for permission when calling a restricted method</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>}</div><div><br></div><div>2. Allows a module with native access enabled to grant permissions to other modules:</div><div><br></div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>```java</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>module org.glavo.myapp {</div><div> requires native;<br></div><div> requires org.glavo.mylib;</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> opens native to org.glavo.mylib;</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>}</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>3. If the main module requires native access, it is allowed without the --enable-native-access.</div><div><br></div><div>4. Allows users to declare restricted methods. </div><div> This will prevent code from masking its true intent through low-level libraries like JNA/JNR.</div><div><br></div></div></div></div></div></div></div></div></blockquote>Glavo</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023 at 12:39 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<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>