<div dir="auto"><div>> Users have always had the right to know what they're doing if they want to.</div><div dir="auto"><br></div><div dir="auto">How, today, can a user know if they use JNI? </div><div dir="auto">The point is to make it impossible for a user to be unaware of any JNI uses which *at the very minimum* requires you to declare it in the command line.</div><div dir="auto"><br></div><div dir="auto">Although *I absolutely* agree that it should also be added to the module-info, so instead of having to specify every module that uses JNI in the flag, you could only specify the Main module, and in there it's module-info will open the JNI usage for every module.</div><div dir="auto"><br></div><div dir="auto">But i don't think there is a way to make sure the users are aware of JNI usage without at least 1 flag<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023, 00:34 Glavo <<a href="mailto:zjx001202@gmail.com">zjx001202@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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">But as Brian said, "This user has a right to know what their application<br>is doing."<br></blockquote><div><br></div><div>Users have always had the right to know what they're doing if they want to.<br></div><div><br></div><div>You don't give users any new powers, you just impose obligations on everyone, so that users have to know more details, </div><div>and library maintainers have to make more implementation details a public behavior that must maintain compatibility.<br></div><div><br></div><div>Glavo </div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023 at 5:17 AM Alex Buckley <<a href="mailto:alex.buckley@oracle.com" target="_blank" rel="noreferrer">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">On 8/28/2023 12:31 PM, Glavo wrote:<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>
> I totally disagree.<br>
> <br>
> --enable-native-access and --add-opens are doing the opposite:<br>
> --add-opens protects implementation details, but --enable-native-access <br>
> exposes implementation details.<br>
> <br>
> Since we have opens, --add-opens is just an escape hatch;<br>
> but --enable-native-access is the only way to enable native access.<br>
<br>
Correct. The common thread -- hence a command line option in both cases <br>
-- is when a library's behavior presents a risk to the user: using JDK <br>
internals that can change from release to release without any warning, <br>
and invoking native code that can undermine the JVM. There is no risk <br>
from libraries that use only public java.* APIs (including the <br>
java.lang.foreign classes for off-heap memory management) and do not <br>
invoke native code.<br>
<br>
> I agree that we should make application assemblers aware of some things,<br>
> but I absolutely disagree that this should break encapsulation.<br>
<br>
By "break encapsulation", I think you mean "expose users to the <br>
implementation detail that a library, which is used by a dependency of a <br>
dependency of a dependency of the application, invokes native code."<br>
<br>
But as Brian said, "This user has a right to know what their application <br>
is doing."<br>
<br>
Alex<br>
<br>
> Also, I'm very much against some things that can only be achieved by <br>
> adding JVM options.<br>
> We have Add-Opens and Enable-Native-Access in the MANIFEST.MF,<br>
> so why are we not allowed to declare them in the main module?<br>
> From what I've seen, some developers have given up on using JPMS in <br>
> their programs because of this.<br>
> I can't understand any benefit of it.<br>
> <br>
> Glavo<br>
> <br>
> On Tue, Aug 29, 2023 at 3:02 AM Alex Buckley <<a href="mailto:alex.buckley@oracle.com" target="_blank" rel="noreferrer">alex.buckley@oracle.com</a> <br>
> <mailto:<a href="mailto:alex.buckley@oracle.com" target="_blank" rel="noreferrer">alex.buckley@oracle.com</a>>> wrote:<br>
> <br>
> Usage of JNI *or the foreign-function parts of the FFM API* will<br>
> require<br>
> the end user of a library to acknowledge that native code is going<br>
> 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<br>
> point is<br>
> to acknowledge risk *from outside the program*. Why? Because if a<br>
> 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<br>
> 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<br>
> app or<br>
> > library. I know that launchers exist, and I know that the<br>
> 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<br>
> usage<br>
> > of JNI in the future will require the end user of a library to<br>
> 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,<br>
> both<br>
> > options often require a bit of rethinking about how they should<br>
> build<br>
> > their project. It's not an easy solution, and it certainly makes<br>
> things<br>
> > more annoying if a library just wants to use some more advanced<br>
> 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" rel="noreferrer">brian.goetz@oracle.com</a> <mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer">brian.goetz@oracle.com</a>><br>
> <mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer">brian.goetz@oracle.com</a> <mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer">brian.goetz@oracle.com</a>>>>:<br>
> ><br>
> > I think you have a serious misunderstanding of what is being<br>
> proposed<br>
> > here. Nobody is taking away JNI. What is being taken away<br>
> 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<br>
> called the<br>
> > "application assembler." This user has a right to know what<br>
> their<br>
> > application is doing.<br>
> ><br>
> > When we started to enforce the accessibility model in Java 9,<br>
> 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<br>
> the user has<br>
> > a chance to consent to relaxed integrity. JNI is the same;<br>
> 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<br>
> they have the<br>
> > ability to make a judgement call on whether they are willing<br>
> 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<br>
> shouldn't be<br>
> > > restricted in a manner like this. It's a powerful, useful<br>
> tool, and<br>
> > > should be treated like that. Developers should have that<br>
> option<br>
> > freely<br>
> > > available.<br>
> ><br>
> <br>
</blockquote></div>
</blockquote></div></div></div>