JEP draft: Prepare to Restrict The Use of JNI

[Maurizio Cimadamore]

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

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