<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">I also agree with Constantin. For many small programs, I don't want to create startup scripts.<br></div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>There are two types of JVM options:</div><div><ol><li> The necessary options for starting the program;</li><li>Additional adjustment options.<br></li></ol><div>I always want my programs to have no necessary JVM options.<br></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Java has been adding lots of features to simplify small applications<br>written and maintained by one person: the single-file source launcher<br>(multi-file coming soon...), more "batteries included" (e.g., the Class<br>File API, the simple web server), and all the Amber features like sealed<br>classes that make code self-documenting.<br></blockquote><div><br></div><div>So why do you still want to do the opposite? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At the same time, we're concerned about large applications, sitting on<br>top of hundreds of libraries, whose maintainers have no overlap with the<br>authors. Adding strong encapsulation of JDK modules, and disabling<br>dynamic agent attach and native access by default, aim to ensure that<br>maintainers know what their application is doing, so they can better<br>manage the risks of adopting a new JDK, new OS, new libraries, etc.<br></blockquote><div><br></div><div>A deep dive into every library isn't necessary for everyone.</div><div>If lib1 trusts lib2 it depends on, then most users who trust lib1 don't need to investigate lib2.</div><div>We shouldn't make the majority of people pay for a very small number of needs.</div><div dir="ltr"><br></div><div dir="ltr">Glavo</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 3:02 AM Alex Buckley <<a href="mailto:alex.buckley@oracle.com">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>