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

[Alex Buckley]

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.
>