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

[Alex Buckley]

On 8/28/2023 12:31 PM, Glavo wrote:
>     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.
> 
> I totally disagree.
> 
> --enable-native-access and --add-opens are doing the opposite:
> --add-opens protects implementation details, but --enable-native-access 
> exposes implementation details.
> 
> Since we have opens, --add-opens is just an escape hatch;
> but --enable-native-access is the only way to enable native access.

Correct. The common thread -- hence a command line option in both cases 
-- is when a library's behavior presents a risk to the user: using JDK 
internals that can change from release to release without any warning, 
and invoking native code that can undermine the JVM. There is no risk 
from libraries that use only public java.* APIs (including the 
java.lang.foreign classes for off-heap memory management) and do not 
invoke native code.

> I agree that we should make application assemblers aware of some things,
> but I absolutely disagree that this should break encapsulation.

By "break encapsulation", I think you mean "expose users to the 
implementation detail that a library, which is used by a dependency of a 
dependency of a dependency of the application, invokes native code."

But as Brian said, "This user has a right to know what their application 
is doing."

Alex

> Also, I'm very much against some things that can only be achieved by 
> adding JVM options.
> We have Add-Opens and Enable-Native-Access in the MANIFEST.MF,
> so why are we not allowed to declare them in the main module?
>  From what I've seen, some developers have given up on using JPMS in 
> their programs because of this.
> I can't understand any benefit of it.
> 
> Glavo
> 
> On Tue, Aug 29, 2023 at 3:02 AM Alex Buckley <alex.buckley at oracle.com 
> <mailto: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>
>     <mailto: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.
>      >
>