JEP draft: Prepare to Restrict The Use of JNI

[Volker Simonis]

On Wed, Aug 23, 2023 at 8:47 AM Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> Hi Volker, some replies inline:
>
> > I have two more questions regarding this proposal:
> >
> > First, will this be a restriction enforced by the Java SE
> > specification? I.e. will the specification require that every Java SE
> > compliant implementation has to restrict JNI by default or will it be
> > up to the vendors to set `--enable-native-access` more liberal in
> > their implementation?
>
> Yes, the restrictions on the use of JNI will be part of the Java SE
> specification. The JEP's Scope is "SE". Restricted methods in the Java
> SE API, whose use causes a warning, were first specified in Java SE 19.
> You can see the list of restricted methods in Java SE 21 here:
>
> https://cr.openjdk.org/~iris/se/21/spec/pr/java-se-21-pr-spec/index.html#Restricted-methods
>

I think it is a little unfortunate that the specification of
"Restricted Methods" is buried in the documentation of the
java.lang.foreign package [1] which is "only" a preview feature. Apart
from there it is mentioned neither in the Java Language Specification
nor in the JVM specification (as far as I can see).

If "Restricted Methods" will be used more broadly and enforced by the
SE specification it think it makes sense to introduce a new,
@Documented annotation (e.g. @Restricted) to make the restricted
nature of specific methods more explicit. This would also make it
possible for tools like compilers/IDEs to flag this methods at
development/build time (similar to @Deprecated). Just mentioning that
a method is restricted somewhere down in their API documentation ( see
e.g. java.lang.foreign.Linker.nativeLinker()) doesn't seem to reflect
the impact of this attribute.

[1] https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/foreign/package-summary.html#restricted
[2] https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/foreign/Linker.html#nativeLinker()

> As such, the four methods listed in the JEP would be added to that list
> in Java SE NN.
>
> We intend to specify that the use of restricted methods causes an error,
> rather than a warning, in some future Java SE specification after Java
> SE NN.
>
> The restrictions on the use of native methods in ordinary code would be
> specified alongside the rules for restricted methods in the Java SE API.
> Without getting into Platform Spec details here, it would be specified
> that a single mechanism disables the restrictions on the use of native
> methods _and_ allows the use of restricted methods.
> > Second, the JEP doesn't mention system and JDK classes. I expect that
> > system classes will be allowed to do JNI by default (e.g. users won't
> > have to grant them native access just because they want to do file I/O
> > or use AWT). But what about platform classes or modules bundled with a
> > JDK distribution which require native access? E.g. vendors bundle a
> > library like OpenJFX (as Oracle did up to JDK 8) or ship some custom
> > security providers (like OracleUcrypto) with their JDK, will it be
> > easily possible and allowed by the Java SE specification, to grant
> > these libraries native access by default? I think some clarifications
> > on this topic in the JEP would be helpful.
>
> True.  Our current thinking (not yet reflected in the JEP) is that:
>
> * all modules associated with either boot loader, or platform loader can
> perform native access
> * additionally, a set of nominated JDK modules associated with the
> application loader can also be enabled for native access (example:
> jdk.internal.le)
>
> The mechanism on how this is done exactly is still not set in stone - it
> might be some build configuration (e.g. look at [1]), or it might be in
> the form of additional flags injected in the JDK image at jlink time
> (e.g. using the `--add-options` plugin, like jextract does [2]).
> Whatever the mechanism, 3rd party JDK implementations will be able to
> add to the list of allowed modules.
>
> Cheers
> Maurizio
>
> [1] -
> https://github.com/openjdk/jdk/blob/master/make/conf/module-loader-map.conf
> [2] - https://github.com/openjdk/jextract/blob/master/build.gradle#L97