<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">All the ideas about enabling native access *from inside the program* --<br>typically in a module declaration -- are missing the point. The point is<br>to acknowledge risk *from outside the program*. Why? Because if a module<br>could silently enable native access, then it will (just as it would if<br>it could silently perform an --add-opens), and users will be unaware of<br>the risks posed to the application they are using.</blockquote><div dir="ltr"><br></div><div dir="ltr">I totally disagree. </div><div dir="ltr"><br></div><div dir="ltr">--enable-native-access and --add-opens are doing the opposite:<br></div><div dir="ltr">--add-opens protects implementation details, but --enable-native-access exposes implementation details.<br></div><div dir="ltr"><br></div><div dir="ltr">Since we have opens, --add-opens is just an escape hatch; </div><div dir="ltr">but --enable-native-access is the only way to enable native access.<br></div><div dir="ltr"><br></div><div dir="ltr">I agree that we should make application assemblers aware of some things, </div><div dir="ltr">but I absolutely disagree that this should break encapsulation.<br></div><div dir="ltr">Also, I'm very much against some things that can only be achieved by adding JVM options.<br></div><div dir="ltr">We have Add-Opens and Enable-Native-Access in the MANIFEST.MF, </div><div dir="ltr">so why are we not allowed to declare them in the main module?<br></div><div dir="ltr">From what I've seen, some developers have given up on using JPMS in their programs because of this.<br></div><div dir="ltr">I can't understand any benefit of it.<br></div><div dir="ltr"><br></div><div dir="ltr">Glavo</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 3:02 AM Alex Buckley <<a href="mailto:alex.buckley@oracle.com" target="_blank">alex.buckley@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">Usage of JNI *or the foreign-function parts of the FFM API* will require <br>
the end user of a library to acknowledge that native code is going to be <br>
invoked.<br>
<br>
(The *foreign-memory parts of the FFM API* are not involved in this <br>
discussion, and their ability to manage off-heap memory will supersede <br>
many traditional uses of JNI and --enable-native-access.)<br>
<br>
Who is the end user of a library? It's an *application* which, in the <br>
vast majority of cases, already has a startup script. What does the <br>
startup script do today?<br>
<br>
- Choose a GC and (sometimes) set GC tuning parameters<br>
- Set system properties to configure security protocols<br>
- Use --add-opens/exports to acknowledge that third, fourth, fifth<br>
party dependencies may try to use setAccessible to access<br>
non-standard JDK internals which can change at any time --<br>
that is, acknowledge risk from libraries which can prevent the<br>
application being run on newer JDKs.<br>
<br>
To this list, we're proposing to add:<br>
<br>
- Use --enable-native-access to acknowledge that third, fourth,<br>
fifth party dependencies may use JNI or parts of the FFM<br>
API which, despite being standard features of the Java Platform,<br>
are inherently dangerous -- that is, acknowledge risk from libraries<br>
which can prevent the application running correctly.<br>
<br>
The risk from libraries using setAccessible on JDK internals is bad: <br>
exceptions are thrown when the internals change, and applications which <br>
ran on JDK 8 don't run on JDK 17. But the risk from libraries invoking <br>
native code are potentially catastrophic: undefined behavior, silent <br>
data corruption, JVM crashes. That's why we propose that the end user <br>
(application assembler) must be aware of the risks.<br>
<br>
All the ideas about enabling native access *from inside the program* -- <br>
typically in a module declaration -- are missing the point. The point is <br>
to acknowledge risk *from outside the program*. Why? Because if a module <br>
could silently enable native access, then it will (just as it would if <br>
it could silently perform an --add-opens), and users will be unaware of <br>
the risks posed to the application they are using.<br>
<br>
Alex<br>
<br>
On 8/28/2023 10:01 AM, Constantin Christoph wrote:<br>
> I am very aware of what is being changed here; I know that JNI will <br>
> still be around, and be usable. However, the restrictions that are going <br>
> to be imposed on using it won't exactly make it easier to use, and <br>
> require even more boilerplate setup for an end user to set up an app or <br>
> library. I know that launchers exist, and I know that the manifest can <br>
> also permit the usage of JNI, but if it would solve the issue, I <br>
> wouldn't be here talking about it. The issue at hand is that the usage <br>
> of JNI in the future will require the end user of a library to either <br>
> make a startup script (which is not always the default procedure for <br>
> smaller applications), or to add another entry to their manifest, both <br>
> options often require a bit of rethinking about how they should build <br>
> their project. It's not an easy solution, and it certainly makes things <br>
> more annoying if a library just wants to use some more advanced features.<br>
> <br>
> Am Mo., 28. Aug. 2023 um 18:39 Uhr schrieb Brian Goetz <br>
> <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a> <mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>>:<br>
> <br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> freely<br>
> > available.<br>
> <br>
</blockquote></div>