JEP draft: Prepare to Restrict The Use of JNI

[Anthony Scarpino]

Sorry. That was related to some crypto JCE that was suppose to be to one person.  Replied to the wrong email. Sigh. 

Tony

> On Aug 23, 2023, at 10:02 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> Yeah. You saw Ron’s reply had that bit too that jdk modules will have native on by default. Jipher looks like it will need either cli permission or if we grant something via JCA.
> 
> Tony
> 
>> On 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
>> 
>> 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