[External] : Re: JEP draft: Prepare to Restrict The Use of JNI

Mon Aug 28 19:51:29 UTC 2023

I also agree with Constantin. For many small programs, I don't want to
create startup scripts.

Who is the end user of a library? It's an *application* which, in the
> vast majority of cases, already has a startup script. What does the
> startup script do today?
>
> - Choose a GC and (sometimes) set GC tuning parameters
> - Set system properties to configure security protocols
> - Use --add-opens/exports to acknowledge that third, fourth, fifth
>    party dependencies may try to use setAccessible to access
>    non-standard JDK internals which can change at any time --
>    that is, acknowledge risk from libraries which can prevent the
>    application being run on newer JDKs.
>

There are two types of JVM options:

   1.  The necessary options for starting the program;
   2. Additional adjustment options.

I always want my programs to have no necessary JVM options.

Java has been adding lots of features to simplify small applications
> written and maintained by one person: the single-file source launcher
> (multi-file coming soon...), more "batteries included" (e.g., the Class
> File API, the simple web server), and all the Amber features like sealed
> classes that make code self-documenting.
>

So why do you still want to do the opposite?

At the same time, we're concerned about large applications, sitting on
> top of hundreds of libraries, whose maintainers have no overlap with the
> authors. Adding strong encapsulation of JDK modules, and disabling
> dynamic agent attach and native access by default, aim to ensure that
> maintainers know what their application is doing, so they can better
> manage the risks of adopting a new JDK, new OS, new libraries, etc.
>

A deep dive into every library isn't necessary for everyone.
If lib1 trusts lib2 it depends on, then most users who trust lib1 don't
need to investigate lib2.
We shouldn't make the majority of people pay for a very small number of
needs.

Glavo

On Tue, Aug 29, 2023 at 3:02 AM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Usage of JNI *or the foreign-function parts of the FFM API* will require
> the end user of a library to acknowledge that native code is going to be
> invoked.
>
> (The *foreign-memory parts of the FFM API* are not involved in this
> discussion, and their ability to manage off-heap memory will supersede
> many traditional uses of JNI and --enable-native-access.)
>
> Who is the end user of a library? It's an *application* which, in the
> vast majority of cases, already has a startup script. What does the
> startup script do today?
>
> - Choose a GC and (sometimes) set GC tuning parameters
> - Set system properties to configure security protocols
> - Use --add-opens/exports to acknowledge that third, fourth, fifth
>    party dependencies may try to use setAccessible to access
>    non-standard JDK internals which can change at any time --
>    that is, acknowledge risk from libraries which can prevent the
>    application being run on newer JDKs.
>
> To this list, we're proposing to add:
>
> - Use --enable-native-access to acknowledge that third, fourth,
>    fifth party dependencies may use JNI or parts of the FFM
>    API which, despite being standard features of the Java Platform,
>    are inherently dangerous -- that is, acknowledge risk from libraries
>    which can prevent the application running correctly.
>
> The risk from libraries using setAccessible on JDK internals is bad:
> exceptions are thrown when the internals change, and applications which
> ran on JDK 8 don't run on JDK 17. But the risk from libraries invoking
> native code are potentially catastrophic: undefined behavior, silent
> data corruption, JVM crashes. That's why we propose that the end user
> (application assembler) must be aware of the risks.
>
> All the ideas about enabling native access *from inside the program* --
> typically in a module declaration -- are missing the point. The point is
> to acknowledge risk *from outside the program*. Why? Because if a module
> could silently enable native access, then it will (just as it would if
> it could silently perform an --add-opens), and users will be unaware of
> the risks posed to the application they are using.
>
> Alex
>
> On 8/28/2023 10:01 AM, Constantin Christoph wrote:
> > 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.
> >
> > Am Mo., 28. Aug. 2023 um 18:39 Uhr schrieb Brian Goetz
> > <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>:
> >
> >     I think you have a serious misunderstanding of what is being proposed
> >     here.  Nobody is taking away JNI.  What is being taken away is the
> >     ability to bury the use of JNI in a library where the user is
> >     unaware of
> >     it.  By "user" here, I mean the person putting together a Java
> >     application from a group of modules and JARs -- sometimes called the
> >     "application assembler."  This user has a right to know what their
> >     application is doing.
> >
> >     When we started to enforce the accessibility model in Java 9, we
> didn't
> >     take away the ability to do deep reflection, we took away the
> >     ability to
> >     do so _without the user knowing_.  The reason that the various
> >     `--add-opens` are specified on the command line is so that the user
> has
> >     a chance to consent to relaxed integrity.  JNI is the same; we're not
> >     taking it away, but we're helping the user be aware of when a
> >     library is
> >     putting the integrity of the application at risk, so that they have
> the
> >     ability to make a judgement call on whether they are willing to trust
> >     that library.
> >
> >
> >     On 8/28/2023 11:37 AM, Constantin Christoph wrote:
> >      >
> >      > JNI is a fundamental part of the java ecosystem, and it shouldn't
> be
> >      > restricted in a manner like this. It's a powerful, useful tool,
> and
> >      > should be treated like that. Developers should have that option
> >     freely
> >      > available.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230829/794660e2/attachment-0001.htm>