Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]

2024-05-22 Thread Kevin Rushforth
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore  
wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting 
>> the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is 
>> now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted 
>> methods, even for FFM API calls. In Java 22, the single 
>> `--enable-native-access` was used both to specify a set of modules for which 
>> native access should be allowed *and* to specify whether illegal native 
>> access (that is, native access occurring from a module not specified by 
>> `--enable-native-access`) should be treated as an error or a warning. More 
>> specifically, an error is only issued if the `--enable-native-access flag` 
>> is used at least once.
>> 
>> Here, a new flag is introduced, namely 
>> `illegal-native-access=allow/warn/deny`, which is used to specify what 
>> should happen when access to a restricted method and/or functionality is 
>> found outside the set of modules specified with `--enable-native-access`. 
>> The default policy is `warn`, but users can select `allow` to suppress the 
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This 
>> aligns the treatment of restricted methods with other mechanisms, such as 
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for 
>> `java.lang.foreign`, to reflect the changes in the command line flags 
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Address review comments

I tested this with JavaFX and everything is working as I would expect. Without 
any options, I get the expected warnings, one time per modules for the three 
`javafx.*` modules that use JNI. If I pass the `--enable-native-access` options 
at runtime, listing those three modules, there is no warning. Further, I 
confirm that if I pass that option to jlink or jpackage when creating a custom 
runtime, there is no warning.

-

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2072430338


Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]

2024-05-23 Thread Kevin Rushforth
On Thu, 23 May 2024 06:20:51 GMT, Alan Bateman  wrote:

> > Further, I confirm that if I pass that option to jlink or jpackage when 
> > creating a custom runtime, there is no warning.
> 
> Great! What about jpackage without a custom runtime, wondering if 
> --java-options can be tested.

Yes, pointing to an existing runtime works, too. In either mode (jpackage using 
an existing Java runtime vs running jlink to create a new one), the options 
specified by `jpackage --java-options` are written to the application's `.cfg` 
file and used when the application launcher is run.

-

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2127188783