From mcimadamore at openjdk.org  Mon May 13 11:08:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:08:51 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the
 Use of JNI
Message-ID: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>

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.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/19213/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331671
  Stats: 466 lines in 99 files changed: 301 ins; 53 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From mcimadamore at openjdk.org  Mon May 13 11:08:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:08:51 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>

On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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.

Javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/javadoc/api/index.html
Specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/specdiff_out/overview-summary.html

make/conf/module-loader-map.conf line 105:

> 103:     java.smartcardio \
> 104:     jdk.accessibility \
> 105:     jdk.attach \

The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.

src/hotspot/share/prims/nativeLookup.cpp line 277:

> 275: 
> 276:   Klass*   klass = vmClasses::ClassLoader_klass();
> 277:   Handle jni_class(THREAD, method->method_holder()->java_mirror());

This is the biggest change in this PR. That is, we need to pass enough arguments to `ClassLoader::findNative` so that the method can start a restricted check accordingly.

src/java.base/share/classes/java/lang/Module.java line 311:

> 309:         Module target = moduleForNativeAccess();
> 310:         ModuleBootstrap.IllegalNativeAccess illegalNativeAccess = ModuleBootstrap.illegalNativeAccess();
> 311:         if (illegalNativeAccess != ModuleBootstrap.IllegalNativeAccess.ALLOW &&

There are some changes in this code:
* this code is no-op if `--illegal-native-access` is set to `allow`
* we also attach the location of the problematic class to the warning message, using `CodeSource`
* we use the "initial error stream" to emit the warning, similarly to what is done for other runtime warnings

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 115:

> 113:     @ForceInline
> 114:     public static void ensureNativeAccess(Class<?> currentClass, Class<?> owner, String methodName) {
> 115:         if (VM.isModuleSystemInited()) {

If we call this code too early, we can see cases where `module` is `null`.

src/java.desktop/macosx/classes/com/apple/eio/FileManager.java line 61:

> 59:     }
> 60: 
> 61:     @SuppressWarnings({"removal", "restricted"})

There are several of these changes. One option might have been to just disable restricted warnings when building. But on a deeper look, I realized that in all these places we already disabled deprecation warnings for the use of security manager, so I also added a new suppression instead.

test/jdk/java/foreign/enablenativeaccess/panama_jni_load_module/module-info.java line 24:

> 22:  */
> 23: 
> 24: module panama_jni_load_module {

This module setup is a bit convoluted, but I wanted to make sure that we got separate warnings for `System.loadLibrary` and binding of the `native` method, and that warning on the _use_ of the native method was not generated (typically, all three operations occur in the same module).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107272261
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598269825
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598271285
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598274987
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598276455
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598277853
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598279827

From mcimadamore at openjdk.org  Mon May 13 11:42:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:42:04 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v2]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>

> 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:

  Avoid call to VM::isModuleSystemInited
  Use initial error stream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/d9fe9a71..c4938dc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=00-01

  Stats: 11 lines in 2 files changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From mcimadamore at openjdk.org  Mon May 13 11:42:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:42:04 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v2]
In-Reply-To: <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>
Message-ID: <I64gRu7YBocAbIcJtlBlzXf9kdrDhS8Qu93w-dKXlOY=.ce21de82-c7e0-4a51-b36a-ae8fc88a8ec1@github.com>

On Mon, 13 May 2024 11:38:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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:
> 
>   Avoid call to VM::isModuleSystemInited
>   Use initial error stream

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 124:

> 122:         if (module != null) {
> 123:             // not in init phase
> 124:             Holder.JLA.ensureNativeAccess(module, owner, methodName, currentClass);

In an earlier iteration I had a call to `VM::isModuleSystemInited`, but I discovered that caused a performance regression, since that method involves a volatile access. Perhaps we should rethink that part of the init code to use stable fields, but it's probably better done separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598328283

From mcimadamore at openjdk.org  Mon May 13 11:47:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:47:38 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>

> 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 three additional commits since the last revision:

 - Fix another typo
 - Fix typo
 - Add more comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/c4938dc7..bad10942

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=01-02

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From erikj at openjdk.org  Mon May 13 13:23:11 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 May 2024 13:23:11 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <SWx03p48zvHP1Ij-QdX_jp8Asy7CJKXNeN22LE20H9Q=.f966cc14-6d7d-48b0-96f9-6f04efa105b2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

Build changes look good.

-------------

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

From weijun at openjdk.org  Mon May 13 13:48:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 13 May 2024 13:48:23 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <aWi7nGuAWfgfr8Zav9c827Na7XNHhgqJyW30njaf3IU=.435796f8-6007-4d00-ac3e-afc3a07e1d3c@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

security changes (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`, and `jdk.security.auth`) look good.

-------------

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

From dfuchs at openjdk.org  Mon May 13 14:18:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 May 2024 14:18:11 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <YAZUq9RulpAueG36Dq_BhXOH2xeUZVgZCK59PdoR4fQ=.b40434ab-ee39-4e7c-90ec-49655dfa54a2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

Changes to jdk.net and jdk.sctp look ok.

-------------

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

From alanb at openjdk.org  Mon May 13 15:35:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 15:35:08 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

src/hotspot/share/runtime/arguments.cpp line 2271:

> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
> 2271:         return JNI_ENOMEM;

I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598673962

From duke at openjdk.org  Tue May 14 01:03:09 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 14 May 2024 01:03:09 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <wH9oXMHtE8zC39h51asmc0gpIjJVuYF6uah2-m5Nf2k=.db1cd4c5-8933-4ae2-ab50-d022636ba24b@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

src/hotspot/share/prims/nativeLookup.cpp line 275:

> 273: 
> 274:   // Otherwise call static method findNative in ClassLoader
> 275: 

Suggestion:

src/hotspot/share/prims/nativeLookup.cpp line 419:

> 417:   if (entry != nullptr) return entry;
> 418: 
> 419: 

Suggestion:

src/hotspot/share/prims/nativeLookup.cpp line 426:

> 424:       return nullptr;
> 425:     }
> 426:   }

Suggestion:

  }

src/java.base/share/classes/java/lang/Module.java line 331:

> 329:                 String modflag = isNamed() ? getName() : "ALL-UNNAMED";
> 330:                 String caller = currentClass != null ? currentClass.getName() : "code";
> 331:                 System.err.printf("""

This?message should?probably be?different when?linking native?methods, since otherwise it?ll be:

WARNING: A restricted method in foo has been called
WARNING: bar has been called by Baz in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled


when?it?should really?be something?like:

WARNING: A JNI native method in foo has been linked
WARNING: bar has been linked in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for native methods in this module
WARNING: Native methods will be blocked in a future release unless native access is enabled

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248442
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248501
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248577
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599253428

From mcimadamore at openjdk.org  Tue May 14 18:10:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 14 May 2024 18:10:28 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v4]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>

> 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 two additional commits since the last revision:

 - Address review comments
   Improve warning for JNI methods, similar to what's described in JEP 472
   Beef up tests
 - Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/bad10942..0d21bf99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=02-03

  Stats: 84 lines in 15 files changed: 42 ins; 14 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From dholmes at openjdk.org  Wed May 15 01:04:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 May 2024 01:04:01 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v4]
In-Reply-To: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
Message-ID: <Nug6-9W3vYrLZVsbSccwpBqVwwzzWuThfLrA-JOjh5Y=.6dc93c53-8683-4b56-a550-cdf6a7928bf2@github.com>

On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 two additional commits since the last revision:
> 
>  - Address review comments
>    Improve warning for JNI methods, similar to what's described in JEP 472
>    Beef up tests
>  - Address review comments

Hotspot changes look good - notwithstanding discussion about properlty namespace placement. Manpage changes also look good.

-------------

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

From dholmes at openjdk.org  Wed May 15 01:04:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 May 2024 01:04:02 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
Message-ID: <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>

On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix another typo
>>  - Fix typo
>>  - Add more comments
>
> src/hotspot/share/runtime/arguments.cpp line 2271:
> 
>> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
>> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
>> 2271:         return JNI_ENOMEM;
> 
> I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.

So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1600819327

From alanb at openjdk.org  Wed May 15 06:18:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 06:18:02 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
Message-ID: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>

On Wed, 15 May 2024 00:54:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2271:
>> 
>>> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
>>> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
>>> 2271:         return JNI_ENOMEM;
>> 
>> I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.
>
> So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?

That's my recollection too. The usage here isn' related to modules which makes me wonder if this function should be renamed (not by this PR of course) of if we should be using PropertyList_unique_add (with AddProperty, WriteableProperty, InternalProperty) instead. There will be further GNU style options coming that will likely need to map to an internal system property in the same way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601002132

From duke at openjdk.org  Wed May 15 07:59:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 07:59:04 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v4]
In-Reply-To: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
Message-ID: <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>

On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 two additional commits since the last revision:
> 
>  - Address review comments
>    Improve warning for JNI methods, similar to what's described in JEP 472
>    Beef up tests
>  - Address review comments

src/java.base/share/classes/java/lang/Module.java line 334:

> 332:                     System.err.printf("""
> 333:                             WARNING: A native method in %s has been bound
> 334:                             WARNING: %s has been called by %s in %s

Note that this line is still not entirely correct, as for code like:

// in module a:
package a;

import b.Foo;

public class Foo {
	public static void main(String... args) {
		System.load("JNI library implementing Java_b_Bar_nativeMethod");

		Bar.nativeMethod();
	}
}


// in module b:
package b;

public class Bar {
	public static native void nativeMethod();
}


It?ll?show?`Bar` as?the?caller of?`Bar::nativeMethod()`, even?though the?caller is?`Foo` in?this?case, which?is?why I?initially?suggested just?omitting the?caller from?**JNI** linkage?warnings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601140578

From mcimadamore at openjdk.org  Wed May 15 09:59:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 09:59:05 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v4]
In-Reply-To: <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
 <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>
Message-ID: <_MDZPWLFa7qcrmsqMsXDJx6Y5lqfI3E4d6Z6-VKv79g=.ad216d38-b066-47d2-bfcd-31a64052015d@github.com>

On Wed, 15 May 2024 07:55:27 GMT, ExE Boss <duke at openjdk.org> wrote:

> Note that this line is still not entirely correct, as for code like:

You are correct - the message is however consistent with what written in JEP 472. I'll discuss with @pron

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601335120

From mcimadamore at openjdk.org  Wed May 15 10:37:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:37:24 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
 <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
Message-ID: <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>

On Wed, 15 May 2024 06:15:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?
>
> That's my recollection too. The usage here isn' related to modules which makes me wonder if this function should be renamed (not by this PR of course) of if we should be using PropertyList_unique_add (with AddProperty, WriteableProperty, InternalProperty) instead. There will be further GNU style options coming that will likely need to map to an internal system property in the same way.

I don't fully agree that this option is not module related (which is why I gave it that name). The very definition of illegal native access is related to native access occurring from a module that is outside a specific set. So I think it's 50/50 as to whether this option is module-related or not. Of course I can fix the code if there's something clearly better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601386336

From mcimadamore at openjdk.org  Wed May 15 10:40:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:40:34 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v5]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>

> 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:

  Refine warning text for JNI method binding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/0d21bf99..daf729f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=03-04

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From alanb at openjdk.org  Wed May 15 11:05:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 11:05:14 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v3]
In-Reply-To: <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
 <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
 <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>
Message-ID: <DLv_q_jPw8OfE2JXGhq-Fk_y3HAET55Fl8as0LvO7zo=.ee2d56a3-aee4-45e7-8bc3-b8ef89778480@github.com>

On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I don't fully agree that this option is not module related (which is why I gave it that name). The very definition of illegal native access is related to native access occurring from a module that is outside a specific set. So I think it's 50/50 as to whether this option is module-related or not. Of course I can fix the code if there's something clearly better.

It maps here to a jdk.module.* property so I suppose it's okay. The functions were introduced to create jdk.module.* properties where the values were a set module names or a module path. Maybe these functions should be renamed at some point (not here) as they are more widely useful now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601421535

From alanb at openjdk.org  Wed May 15 15:59:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 15:59:14 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v5]
In-Reply-To: <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>
Message-ID: <suc3iBvDYlNQN67NthCn7mNhES7uotnhpwD94oLIWys=.13442394-d2c1-4118-893b-db62656c6708@github.com>

On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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:
> 
>   Refine warning text for JNI method binding

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 871:

> 869:             return IllegalNativeAccess.WARN;
> 870:         } else {
> 871:             fail("Value specified to --illegal-access not recognized:"

Typo in the message, should be --illegal-native-access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601898238

From mcimadamore at openjdk.org  Wed May 15 16:08:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 16:08:17 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v6]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>

> 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 comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/daf729f4..1c45e5d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From kevinw at openjdk.org  Wed May 15 17:21:10 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 17:21:10 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older JDKs,
 after removing Subject Delegation
Message-ID: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>

Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.

In javax/management/remote/rmi/RMIConnectionImpl.java:
addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).

Manually testing JConsole, the MBean tab is fully populated and usable.

-------------

Commit messages:
 - Remove unnecessary Subject array in RMIConnectionImpl, update docs in RMIConnection
 - JConsole's MBean tab is blank after JMX Subject Delegation removal.

Changes: https://git.openjdk.org/jdk/pull/19253/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332303
  Stats: 18 lines in 2 files changed: 9 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19253/head:pull/19253

PR: https://git.openjdk.org/jdk/pull/19253

From dfuchs at openjdk.org  Wed May 15 17:52:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 15 May 2024 17:52:06 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 984:

> 982:         }
> 983:         if (names.length != filters.length) {
> 984:             final String msg = "The lengths of names and filters parameters are not same.";

I wonder if we should check that if present, `delegationSubjects.length == names.length`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602032906

From cjplummer at openjdk.org  Wed May 15 19:12:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 19:12:01 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <ugl-Oa1mxaS8FULfscylwDHMKXcKSB5QICVfIFN4XRk=.881c1812-b6d6-49b1-b1e4-8896be5000e0@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

I'm just trying to understand current and previous behavior of jconsole a bit better. It sounds like jconsole always passes a non-null `delegationSubjects`, which results in an UOE, and you've changed to code to accept it as long as the entries are all null,  resulting in no UOE and jconsole properly displaying the mbean tab. But what I don't understand is why we are seeing this issue with jconsole when it appears it is already passes null for the `delegationSubjects` argument, even back as far as JDK 8u.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113277694

From kevinw at openjdk.org  Wed May 15 20:05:01 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 20:05:01 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
Message-ID: <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>

On Wed, 15 May 2024 17:49:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 984:
> 
>> 982:         }
>> 983:         if (names.length != filters.length) {
>> 984:             final String msg = "The lengths of names and filters parameters are not same.";
> 
> I wonder if we should check that if present, `delegationSubjects.length == names.length`?

That seems pretty extreme -- it's an array we explicitly don't want and are going to ignore?  If somebody passes a non-null member, we will throw as unsupported.  I was thinking that was enough, hence removing the sbjs array to be quite certain we can't pass on any supplied Subjects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602181014

From kevinw at openjdk.org  Wed May 15 20:29:05 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 20:29:05 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <ugl-Oa1mxaS8FULfscylwDHMKXcKSB5QICVfIFN4XRk=.881c1812-b6d6-49b1-b1e4-8896be5000e0@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <ugl-Oa1mxaS8FULfscylwDHMKXcKSB5QICVfIFN4XRk=.881c1812-b6d6-49b1-b1e4-8896be5000e0@github.com>
Message-ID: <x9i4QY2T69IETnVXf7HQGppcNpqg1p_WzL9EtCpR-bg=.e4a9c2b4-7371-4805-a726-34b561b3930f@github.com>

On Wed, 15 May 2024 19:09:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm just trying to understand current and previous behavior of jconsole a bit better.....

Right, to be clear it's not JConsole's fault.   The early part of JConsole's stack is:


...connection....
	at java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl_Stub.addNotificationListeners(RMIConnectionImpl_Stub.java:136)
	at java.management.rmi/javax.management.remote.rmi.RMIConnector.addListenersWithSubjects(RMIConnector.java:595)
	at java.management.rmi/javax.management.remote.rmi.RMIConnector.addListenerWithSubject(RMIConnector.java:571)
	at java.management.rmi/javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.addNotificationListener(RMIConnector.java:1238)
	at jdk.jconsole/sun.tools.jconsole.MBeansTab$1.doInBackground(MBeansTab.java:93)
...older frames...


...and when it is running with an older JDK, RMIConnector.addListenerWithSubject() would create a new array of Subjects, containing what it was given (which is null).
It passes on the array, and then is going to get the UnsupportedOperationException.
i.e. Older client code passing a null Subject, actually "promotes" it to an array and hits the Exception, although it really is not trying to use the removed feature.

This problem is specifically with addListenerWithSubject.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113397029

From cjplummer at openjdk.org  Wed May 15 21:23:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 21:23:05 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Ok. So the older version of jconsole does pass the empty delegationSubjects, not null. Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113474704

From kevinw at openjdk.org  Wed May 15 21:41:04 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 May 2024 21:41:04 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
Message-ID: <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>

On Wed, 15 May 2024 21:20:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?

I don't think there is, JConsole has a hard null in this call.  Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.

If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone.
Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113498480

From sspitsyn at openjdk.org  Wed May 15 22:48:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 May 2024 22:48:01 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <jNfR8GSfy45jKTdg6SGbLnBMmDBhqzGJKL9NFJko4oU=.2bc63f76-7ff0-4955-9e12-0f0b98c69aa3@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Looks good in general. Posted a couple of questions though.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 979:

> 977:             for (Subject s: delegationSubjects) {
> 978:                 if (s != null) {
> 979:                     throw new UnsupportedOperationException("Subject Delegation has been removed.");

Q1: Would it make sense to provide any details about the failing `delegationSubject` element?
Q2: Does this fix needs a CSR?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19253#pullrequestreview-2059157190
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602337036

From cjplummer at openjdk.org  Wed May 15 23:43:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 May 2024 23:43:01 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
Message-ID: <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>

On Wed, 15 May 2024 21:38:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> > ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?
> 
> I don't think there is, JConsole has a hard null in this call. Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.
> 
> If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone. Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.

If jconsole is passing null, why is it triggering this exception?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2113656022

From kevinw at openjdk.org  Thu May 16 08:28:02 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 08:28:02 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
 <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
Message-ID: <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>

On Wed, 15 May 2024 23:40:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If jconsole is passing null, why is it triggering this exception?

JConsole passes null, but when running on an older jdk, the older RMIConnector actually "promotes" it to an array before making the remote call.  If you connect to a jdk-23 with the removal, the exception is thrown.

(JConsole running on jdk-23 can connect to jdk-23 fine.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2114453521

From kevinw at openjdk.org  Thu May 16 09:05:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 09:05:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <jNfR8GSfy45jKTdg6SGbLnBMmDBhqzGJKL9NFJko4oU=.2bc63f76-7ff0-4955-9e12-0f0b98c69aa3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jNfR8GSfy45jKTdg6SGbLnBMmDBhqzGJKL9NFJko4oU=.2bc63f76-7ff0-4955-9e12-0f0b98c69aa3@github.com>
Message-ID: <8VfBzZdiXsFsNs9s-TbP9pFAxUTBpjGVyicTU-oesK8=.63a74189-cce2-4baa-bfb6-7eb79909c017@github.com>

On Wed, 15 May 2024 22:44:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 979:
> 
>> 977:             for (Subject s: delegationSubjects) {
>> 978:                 if (s != null) {
>> 979:                     throw new UnsupportedOperationException("Subject Delegation has been removed.");
> 
> Q1: Would it make sense to provide any details about the non-null `delegationSubject` element?
> Q2: Does this fix needs a CSR? My guess is that this issue is very minor, so CSR is not needed.

Q1 We have a couple of places where we use that text, when a non-null Subject is given.  It's quite generic and that is a good fit.  Your app would have to go to a significant effort to use the Subject Delegation feature, and we aren't aware of any apps that use it.  If JConsole were using the feature, you would know as you would have had to specifically configure it somehow (as well as on the remote end with SM and policies), so I really think the generic message is explicit enough.

Q2 Yes, Daniel very quickly added the CSR flag.  I was presuming that "paperwork" would need doing, although yes as spec changes go, it is very very minor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1602917924

From dfuchs at openjdk.org  Thu May 16 09:44:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 May 2024 09:44:12 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
Message-ID: <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>

On Wed, 15 May 2024 20:02:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 984:
>> 
>>> 982:         }
>>> 983:         if (names.length != filters.length) {
>>> 984:             final String msg = "The lengths of names and filters parameters are not same.";
>> 
>> I wonder if we should check that if present, `delegationSubjects.length == names.length`?
>
> That seems pretty extreme -- it's an array we explicitly don't want and are going to ignore?  If somebody passes a non-null member, we will throw as unsupported.  I was thinking that was enough, hence removing the sbjs array to be quite certain we can't pass on any supplied Subjects.

Well my thinking was this: the fact that the jconsole tab was blank shows that the array may being passed. The previous code verified that all three arrays had the same length - so it would have failed if the array had a length different than the other two. So I would prefer if we kept on throwing in that case. In other words, we now allow and prefer `null` - but if non-null - we will allow a null-filled array passed by an older client but  we should not accept something that would have been invalid then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603000965

From kevinw at openjdk.org  Thu May 16 10:20:06 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 10:20:06 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
Message-ID: <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>

On Thu, 16 May 2024 09:40:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> That seems pretty extreme -- it's an array we explicitly don't want and are going to ignore?  If somebody passes a non-null member, we will throw as unsupported.  I was thinking that was enough, hence removing the sbjs array to be quite certain we can't pass on any supplied Subjects.
>
> Well my thinking was this: the fact that the jconsole tab was blank shows that the array may being passed. The previous code verified that all three arrays had the same length - so it would have failed if the array had a length different than the other two. So I would prefer if we kept on throwing in that case. In other words, we now allow and prefer `null` - but if non-null - we will allow a null-filled array passed by an older client but  we should not accept something that would have been invalid then.

That the JConsole tab was blank shows that the older RMIConnector's addListenerWithSubject creates a new single-entry array from the given delegationSubject (which is null) and passes it onwards.  The app is not creating the array itself., that's us.

(also, maybe that JConsole relies on listeners in order to show a screen that doesn't really need to depend on them, but this change is obviously about being compatible with that)

We all know that that is the only use case out there, the current wisdom is that this feature is not used, nobody is creating the Subject array and calling addListenersWithSubjects (plural) with it...

IF we find such an app app, we are going to ignore the array unless it contains a non-null entry.  This seems safe and efficient.  We are documenting that it should be null,  and it is weird to document a length requirement for something that should be null...  8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603064299

From dfuchs at openjdk.org  Thu May 16 10:32:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 May 2024 10:32:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
Message-ID: <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>

On Thu, 16 May 2024 10:16:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Well my thinking was this: the fact that the jconsole tab was blank shows that the array may being passed. The previous code verified that all three arrays had the same length - so it would have failed if the array had a length different than the other two. So I would prefer if we kept on throwing in that case. In other words, we now allow and prefer `null` - but if non-null - we will allow a null-filled array passed by an older client but  we should not accept something that would have been invalid then.
>
> That the JConsole tab was blank shows that the older RMIConnector's addListenerWithSubject creates a new single-entry array from the given delegationSubject (which is null) and passes it onwards.  The app is not creating the array itself., that's us.
> 
> (also, maybe that JConsole relies on listeners in order to show a screen that doesn't really need to depend on them, but this change is obviously about being compatible with that)
> 
> We all know that that is the only use case out there, the current wisdom is that this feature is not used, nobody is creating the Subject array and calling addListenersWithSubjects (plural) with it...
> 
> IF we find such an app app, we are going to ignore the array unless it contains a non-null entry.  This seems safe and efficient.  We are documenting that it should be null,  and it is weird to document a length requirement for something that should be null...  8-)

This shows that when SubjectDelegation was not used, a null-filled array of the same length as the two other arrays was expected before (in previous versions of the JDK where SubjectDelegation was supported, but in the case where it wasn't used). 
I am not suggesting to document the length requirement. The length requirement was enforced before and undocumented. I'm just suggesting that we allow null and null-filled but don't allow something (null filled array of wrong length) that would have been rejeceted in previous JDK versions. I would also suggest to check the length before the content - in case an array is supplied.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603087272

From kevinw at openjdk.org  Thu May 16 10:40:02 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 10:40:02 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
 <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
Message-ID: <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>

On Thu, 16 May 2024 10:26:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> That the JConsole tab was blank shows that the older RMIConnector's addListenerWithSubject creates a new single-entry array from the given delegationSubject (which is null) and passes it onwards.  The app is not creating the array itself., that's us.
>> 
>> (also, maybe that JConsole relies on listeners in order to show a screen that doesn't really need to depend on them, but this change is obviously about being compatible with that)
>> 
>> We all know that that is the only use case out there, the current wisdom is that this feature is not used, nobody is creating the Subject array and calling addListenersWithSubjects (plural) with it...
>> 
>> IF we find such an app app, we are going to ignore the array unless it contains a non-null entry.  This seems safe and efficient.  We are documenting that it should be null,  and it is weird to document a length requirement for something that should be null...  8-)
>
> This shows that when SubjectDelegation was not used, a null-filled array of the same length as the two other arrays was expected before (in previous versions of the JDK where SubjectDelegation was supported, but in the case where it wasn't used). 
> I am not suggesting to document the length requirement. The length requirement was enforced before and undocumented. I'm just suggesting that we allow null and null-filled but don't allow something (null filled array of wrong length) that would have been rejeceted in previous JDK versions. I would also suggest to check the length before the content - in case an array is supplied.

Yes, completely understand.  I just don't think it has any benefit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603106058

From jpai at openjdk.org  Thu May 16 11:24:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:24:10 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v6]
In-Reply-To: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
Message-ID: <RUCP0y-ucqEWVGtNsxZ_c5l2t0sddT8sl247K_JYUls=.35b6b052-336b-462e-a19f-84150c738763@github.com>

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 comment

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:

> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
> 72: \                  This option will be removed in a future release.\n\

Should this specify the current default value for this option if it isn't set?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603157916

From dfuchs at openjdk.org  Thu May 16 11:41:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 May 2024 11:41:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
 <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
 <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>
Message-ID: <TExsXOAdzHaqtY5sVv-XWM8I0PV3QPHWEe9_l_dBJcQ=.b555886f-ba6e-491d-889f-7e2c3601b43e@github.com>

On Thu, 16 May 2024 10:37:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This shows that when SubjectDelegation was not used, a null-filled array of the same length as the two other arrays was expected before (in previous versions of the JDK where SubjectDelegation was supported, but in the case where it wasn't used). 
>> I am not suggesting to document the length requirement. The length requirement was enforced before and undocumented. I'm just suggesting that we allow null and null-filled but don't allow something (null filled array of wrong length) that would have been rejeceted in previous JDK versions. I would also suggest to check the length before the content - in case an array is supplied.
>
> Yes, completely understand.  I just don't think it has any benefit.

Hmmm... the spec still says:

     * @throws IllegalArgumentException if <code>names</code> or
     * <code>filters</code> is null, or if <code>names</code> contains
     * a null element, or if the three arrays do not all have the same
     * size.
 ```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603184648

From jpai at openjdk.org  Thu May 16 11:45:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:45:06 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v6]
In-Reply-To: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
Message-ID: <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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 comment

Hello Maurizio, in the current mainline, we have code in `LauncherHelper` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636 where we enable native access to all unnamed modules if an executable jar with `Enable-Native-Access: ALL-UNNAMED` manifest is being launched. For such executable jars, what is the expected semantics when the launch also explicitly has a `--enable-native-access=M1,M2` option. Something like:


java --enable-native-access=M1,M2 -jar foo.jar

where `foo.jar` has `Enable-Native-Access: ALL-UNNAMED` in its manifest.

-------------

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

From kevinw at openjdk.org  Thu May 16 11:46:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 11:46:30 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v2]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  IllegalArgumentException throws doc update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/ef84485e..6c97b5ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19253/head:pull/19253

PR: https://git.openjdk.org/jdk/pull/19253

From kevinw at openjdk.org  Thu May 16 11:46:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 11:46:30 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v2]
In-Reply-To: <TExsXOAdzHaqtY5sVv-XWM8I0PV3QPHWEe9_l_dBJcQ=.b555886f-ba6e-491d-889f-7e2c3601b43e@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <mPPYdU0tjGWpRM0in_MxwPbUblhPXL19Nep9Nrz9dRs=.c594a7b6-7c25-4cbb-b3dd-26cb81356df1@github.com>
 <Qhcs16GkLOdaLWMlOSTYD9DGW4Q5CrHiJ95Hs5LbsJQ=.a3495436-72bb-40c7-a1fd-c33ef04542a2@github.com>
 <K77RnFJzIVNbQG5lFuJdUgT72Gj0o0A29Fe13wl_MBY=.ee6ed0e3-784a-4204-871c-d47533c78dfc@github.com>
 <cwIRphFeBKHxH6n5YKtcpzvEPZXDIrewr47WqhgvEqw=.63cf04b8-339a-4e7c-be28-157df89b3b7d@github.com>
 <i9ZkPnmicV_BYSfd-xYhxKyqwZfhIvFkIFRO1m2YbQ4=.b951b7b9-8430-4bff-86a5-a9a4c45fc0fb@github.com>
 <zKEB_jOaoHXAXJMNie5SHh1CGBHoFsH_dAi_FSa0f70=.7c0605e1-da25-497b-b85a-784403b8c64e@github.com>
 <TExsXOAdzHaqtY5sVv-XWM8I0PV3QPHWEe9_l_dBJcQ=.b555886f-ba6e-491d-889f-7e2c3601b43e@github.com>
Message-ID: <PbXY6y7WNwrx3NStoFzbQwJ04Fw6DqhjvtzjS_b2nQ4=.ef440a2c-138b-4332-89cc-a3729f1f0511@github.com>

On Thu, 16 May 2024 11:38:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Yes, completely understand.  I just don't think it has any benefit.
>
> Hmmm... the spec still says:
> 
>      * @throws IllegalArgumentException if <code>names</code> or
>      * <code>filters</code> is null, or if <code>names</code> contains
>      * a null element, or if the three arrays do not all have the same
>      * size.
>  ```

Thanks for additionally spotting the throws IAE needs updating, adding that now... (Will update the CSR also.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603191504

From mcimadamore at openjdk.org  Thu May 16 11:50:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 11:50:05 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v6]
In-Reply-To: <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
Message-ID: <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>

On Thu, 16 May 2024 11:42:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Maurizio, in the current mainline, we have code in `LauncherHelper` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636 where we enable native access to all unnamed modules if an executable jar with `Enable-Native-Access: ALL-UNNAMED` manifest is being launched. For such executable jars, what is the expected semantics when the launch also explicitly has a `--enable-native-access=M1,M2` option. Something like:
> 
> ```
> java --enable-native-access=M1,M2 -jar foo.jar
> ```
> 
> where `foo.jar` has `Enable-Native-Access: ALL-UNNAMED` in its manifest.

The options are additive - e.g. the enable-native-access in the manifest will add up to the enable-native-access in the command line, so effectively it will be as if you were running with --enable-native-access=M1,M2,ALL-UNNAMED

> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:
> 
>> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
>> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
>> 72: \                  This option will be removed in a future release.\n\
> 
> Should this specify the current default value for this option if it isn't set?

We already do, see
https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2115012361
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603195671

From jpai at openjdk.org  Thu May 16 11:58:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:58:06 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v6]
In-Reply-To: <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
 <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
Message-ID: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>

On Thu, 16 May 2024 11:47:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:
>> 
>>> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
>>> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
>>> 72: \                  This option will be removed in a future release.\n\
>> 
>> Should this specify the current default value for this option if it isn't set?
>
> We already do, see
> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582

This is slightly different from what we do in the other PR for unsafe memory access where we specify the default in the launcher's help text too https://github.com/openjdk/jdk/pull/19174/files#diff-799093930b698e97b23ead98c6496261af1e2e33ec7aa9261584870cbee8a5eaR219.

I don't have a strong opinion on this, I think either one is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603205279

From mcimadamore at openjdk.org  Thu May 16 12:20:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 12:20:05 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v6]
In-Reply-To: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
 <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
 <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>
Message-ID: <qpY76_mtbXFOYTvN5L7CXAZ7ZrsaLRFCjhoRB9WzzEk=.f53b98b1-6ad5-4499-98a0-aa8080b49cf0@github.com>

On Thu, 16 May 2024 11:55:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> We already do, see
>> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582
>
> This is slightly different from what we do in the other PR for unsafe memory access where we specify the default in the launcher's help text too https://github.com/openjdk/jdk/pull/19174/files#diff-799093930b698e97b23ead98c6496261af1e2e33ec7aa9261584870cbee8a5eaR219.
> 
> I don't have a strong opinion on this, I think either one is fine.

Ah, apologies, I was looking in the wrong place. I agree that we should specify default in the launcher, as well as in the man pages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603233038

From mcimadamore at openjdk.org  Thu May 16 12:23:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 12:23:44 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v7]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>

> 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:

  Add note on --illegal-native-access default value in the launcher help

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/1c45e5d5..3a0db276

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From alanb at openjdk.org  Thu May 16 18:43:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 May 2024 18:43:06 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/System.java line 2023:

> 2021:      * @throws     NullPointerException if {@code filename} is {@code null}
> 2022:      * @throws     IllegalCallerException If the caller is in a module that
> 2023:      *             does not have native access enabled.

The exception description is fine, just noticed the other exception descriptions start with a lowercase "if", this one is different.

src/java.base/share/man/java.1 line 587:

> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.

"This mode disable all illegal native access except for those modules enabled the --enable-native-access command-line option". 

This can be read to mean that modules granted native access with the command line option is also illegal native access An alternative is to make the second part of the sentence a new sentence, something like "Only modules enabled by the --enable-native-access command line option may perform native access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920

From mullan at openjdk.org  Thu May 16 20:07:04 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 May 2024 20:07:04 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v2]
In-Reply-To: <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>
Message-ID: <Nmxg_-qsMlNQ1Gk2n3RudAgScntkhtlA7UQmSMmDooU=.0b7b9cb7-b931-4c5b-88ad-44ecd420b30e@github.com>

On Thu, 16 May 2024 11:46:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IllegalArgumentException throws doc update

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 959:

> 957:      * <code>NotificationFilters</code>.  Elements of this array can
> 958:      * be null.
> 959:      * @param delegationSubjects should be {@code null}, but a non-null

Would it be more clear to say: "should be {@code null}. However, an array where every entry is null is also accepted for compatibility reasons."

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 960:

> 958:      * be null.
> 959:      * @param delegationSubjects should be {@code null}, but a non-null
> 960:      * array is accepted for compatibilty reasons, which must not contain

Typo: s/compatibilty/compatibility/

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 969:

> 967:      * @throws IllegalArgumentException if <code>names</code> or
> 968:      * <code>filters</code> is null, or if <code>names</code> contains
> 969:      * a null element, or if these two arrays do not have the same size.

Was this actually an oversight in the previous change to remove subject delegation? When `delegationSubjects` is null, then the 3 arrays are never going to be the same size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603957397
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603965135
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603963533

From kevinw at openjdk.org  Thu May 16 20:17:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 20:17:18 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - add an 'also'
 - typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/6c97b5ed..68c791e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19253/head:pull/19253

PR: https://git.openjdk.org/jdk/pull/19253

From kevinw at openjdk.org  Thu May 16 20:17:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 May 2024 20:17:18 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v2]
In-Reply-To: <Nmxg_-qsMlNQ1Gk2n3RudAgScntkhtlA7UQmSMmDooU=.0b7b9cb7-b931-4c5b-88ad-44ecd420b30e@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bPeQvl1ZelVz2y4Q7bMTI6HP7qZD-sc17Q_gWKz4DUU=.3fd5521d-b762-48cd-ba38-52a47698e332@github.com>
 <Nmxg_-qsMlNQ1Gk2n3RudAgScntkhtlA7UQmSMmDooU=.0b7b9cb7-b931-4c5b-88ad-44ecd420b30e@github.com>
Message-ID: <rd5PPDVzoXGoU4ApmUQBP7S5xJppjkuRan6GeQbt-j4=.40adc121-ee90-47f4-b8de-6e85adec5338@github.com>

On Thu, 16 May 2024 19:53:48 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   IllegalArgumentException throws doc update
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 959:
> 
>> 957:      * <code>NotificationFilters</code>.  Elements of this array can
>> 958:      * be null.
>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
> 
> Would it be more clear to say: "should be {@code null}. However, an array where every entry is null is also accepted for compatibility reasons."

Yes, I like adding the "also".

> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 960:
> 
>> 958:      * be null.
>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
>> 960:      * array is accepted for compatibilty reasons, which must not contain
> 
> Typo: s/compatibilty/compatibility/

oops yes thanks, done.

> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 969:
> 
>> 967:      * @throws IllegalArgumentException if <code>names</code> or
>> 968:      * <code>filters</code> is null, or if <code>names</code> contains
>> 969:      * a null element, or if these two arrays do not have the same size.
> 
> Was this actually an oversight in the previous change to remove subject delegation? When `delegationSubjects` is null, then the 3 arrays are never going to be the same size.

Yes, this is an oversight from the previous change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603976969
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603974595
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603975797

From alanb at openjdk.org  Fri May 17 09:34:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:34:11 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <9oh0XZoux2OKBke0T-hr6CS9OsuDD6Wk1HdQdPu2YyY=.1d9a2a75-cb80-498c-86f9-da457669e3e8@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/foreign/package-info.java line 170:

> 168:  * the special value {@code ALL-UNNAMED} can be used). Access to restricted methods
> 169:  * from modules not listed by that option is deemed <em>illegal</em>. Clients can
> 170:  * control how illegal access to restricted method is handled, using the command line

I assume this should be "to a restricted method is handled" or "to restricted methods are handled", either would work here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950

From alanb at openjdk.org  Fri May 17 09:40:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:40:21 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <W-o6qMpByBf7fBVE1h-_fFwlI6bTAsGw-4R24hQbBeE=.0a4838db-f222-4155-8bfb-2f8cf52b4eef@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288:

> 286:      * throw exception depending on the configuration.
> 287:      */
> 288:     void ensureNativeAccess(Module m, Class<?> owner, String methodName, Class<?> currentClass, boolean jni);

It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767

From alanb at openjdk.org  Fri May 17 09:44:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:44:05 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <K-ddELjw1PrhIpxriH8mimHSS4zSSzpt-IAoh7D5f3A=.e9b76a6b-b6cb-4e63-93cc-5b06f6aee862@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/ClassLoader.java line 2448:

> 2446:      * Invoked in the VM class linking code.
> 2447:      */
> 2448:     static long findNative(ClassLoader loader, Class<?> clazz, String entryName, String javaName) {

I think this is another place where `@param` descriptions would help as it's not immediately clear that "javaName" is a method name.

src/java.base/share/classes/java/lang/Runtime.java line 39:

> 37: 
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;

Runtime has been touched for a while so you'll need to bump the copyright year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293

From alanb at openjdk.org  Fri May 17 09:48:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:48:13 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <xjxqMo73h5zMqu-HCClmiqySodIWBCGCWfjMa_Y5pa0=.0d5904a7-f027-49b1-bd33-e49ab547551a@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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:
> 
>   Add note on --illegal-native-access default value in the launcher help

This looks good. Just a few minor comments where future maintainers might appreciate comments that describe parameters.

src/java.base/share/classes/java/lang/Module.java line 332:

> 330:                 String caller = currentClass != null ? currentClass.getName() : "code";
> 331:                 if (jni) {
> 332:                     System.err.printf("""

System.err may change in a running VM. It may be that we will need to change this at some point to use its initial setting. Not suggesting we changing it now but we might have to re-visit this.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749

From dfuchs at openjdk.org  Fri May 17 10:18:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 May 2024 10:18:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
Message-ID: <3OdaE4DZRAly2UhwF_fGNloyiG6Pk3vmmRt2Eit-Esk=.2893e7f9-ec35-4331-9570-ed712df9f682@github.com>

On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add an 'also'
>  - typo

Marked as reviewed by dfuchs (Reviewer).

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 979:

> 977:      * @throws IOException if a general communication exception occurred.
> 978:      * @throws UnsupportedOperationException if {@code delegationSubjects}
> 979:      * contains any non-null values.

Suggestion:

     * @throws UnsupportedOperationException if {@code delegationSubjects}
     * is non-null and contains any non-null values.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19253#pullrequestreview-2062912013
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1604707244

From alanb at openjdk.org  Fri May 17 10:38:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 10:38:04 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
Message-ID: <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>

On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add an 'also'
>  - typo

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 961:

> 959:      * @param delegationSubjects should be {@code null}, but a non-null
> 960:      * array is also accepted for compatibility reasons, which must not
> 961:      * contain any non-null entries.

The wording is bit unusual for a parameter description. Just wondering if might be clearer to say "null or an array of null elements" and put add an `@apiNote` to explain that it allows an array with null elements for compatibility reasons. What you have is okay too course, I'm just trying to think of another way to present this odd case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1604740107

From mcimadamore at openjdk.org  Fri May 17 13:23:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 May 2024 13:23:06 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v7]
In-Reply-To: <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
 <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>
Message-ID: <GLNx0ptAp6dY9BORWHEv6XnKqoRWn_QejEmKQ6iY540=.4a5fe98e-b069-4250-b9d2-bbc8f9b89841@github.com>

On Thu, 16 May 2024 18:39:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add note on --illegal-native-access default value in the launcher help
>
> src/java.base/share/classes/java/lang/System.java line 2023:
> 
>> 2021:      * @throws     NullPointerException if {@code filename} is {@code null}
>> 2022:      * @throws     IllegalCallerException If the caller is in a module that
>> 2023:      *             does not have native access enabled.
> 
> The exception description is fine, just noticed the other exception descriptions start with a lowercase "if", this one is different.

I'll fix this. Note that in `ModuleLayer.Controller`, all `@throws` start with capital letter, which is probably where I copied/pasted this from. I'll fix all, except for `ModuleLayer` where, for consistency, I think upper case is better.

> src/java.base/share/man/java.1 line 587:
> 
>> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
>> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
>> 587: command-line option.
> 
> "This mode disable all illegal native access except for those modules enabled the --enable-native-access command-line option". 
> 
> This can be read to mean that modules granted native access with the command line option is also illegal native access An alternative is to make the second part of the sentence a new sentence, something like "Only modules enabled by the --enable-native-access command line option may perform native access.

I've simplified the text to:


This mode disables illegal native access. That is, any illegal native access causes an `IllegalCallerException`.
This mode will become the default in a future release.


I think it's not necessary to state again the dependency on `--enable-native-access` as we already defined what "illegal native access" means.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604994928
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604993505

From mcimadamore at openjdk.org  Fri May 17 13:38:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 May 2024 13:38:25 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/3a0db276..789bdf48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=06-07

  Stats: 28 lines in 10 files changed: 8 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From kevinw at openjdk.org  Fri May 17 16:01:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 May 2024 16:01:24 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v4]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <7gg2ucNT8hZX7N2ivvIjjBWPNTT2yOzYb72f7TvDJzs=.24c63b3c-dec6-49fe-9876-30e1c2d6800f@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  UOE doc correction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/68c791e7..4e8f84ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19253/head:pull/19253

PR: https://git.openjdk.org/jdk/pull/19253

From kevinw at openjdk.org  Fri May 17 16:01:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 May 2024 16:01:25 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <3OdaE4DZRAly2UhwF_fGNloyiG6Pk3vmmRt2Eit-Esk=.2893e7f9-ec35-4331-9570-ed712df9f682@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <3OdaE4DZRAly2UhwF_fGNloyiG6Pk3vmmRt2Eit-Esk=.2893e7f9-ec35-4331-9570-ed712df9f682@github.com>
Message-ID: <uoOuWt-bp7ErFPu606Wni2deBjLkk2VQ7B7Rmlw8kI8=.085e39cf-02c3-4b96-9f0f-924f2e98cd6f@github.com>

On Fri, 17 May 2024 10:14:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add an 'also'
>>  - typo
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 979:
> 
>> 977:      * @throws IOException if a general communication exception occurred.
>> 978:      * @throws UnsupportedOperationException if {@code delegationSubjects}
>> 979:      * contains any non-null values.
> 
> Suggestion:
> 
>      * @throws UnsupportedOperationException if {@code delegationSubjects}
>      * is non-null and contains any non-null values.

Yes, thanks well spotted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1605235219

From jpai at openjdk.org  Sat May 18 11:43:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 May 2024 11:43:02 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <_4CgX7Ojzb5QH2sJ4k2fDgfz_zba03l_4feYaVyzhl0=.a6128ce8-56c3-4b71-a0e3-cf48c9b68c3e@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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

Marked as reviewed by jpai (Reviewer).

-------------

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

From alanb at openjdk.org  Mon May 20 08:12:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 08:12:02 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
 <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
 <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
Message-ID: <6zDrA0b4meB2PNnopX2wSHm3HFBCPScHj4PjBInaF5M=.d8a1e42b-f975-41c0-960c-85e53debb57a@github.com>

On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> > ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?
>>> 
>>> I don't think there is, JConsole has a hard null in this call. Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.
>>> 
>>> If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone. Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.
>> 
>> If jconsole is passing null, why is it triggering this exception?
>
>> If jconsole is passing null, why is it triggering this exception?
> 
> JConsole passes null, but when running on an older jdk, the older RMIConnector actually "promotes" it to an array before making the remote call.  If you connect to a jdk-23 with the removal, the exception is thrown.
> 
> (JConsole running on jdk-23 can connect to jdk-23 fine.)
> (Also just to note, a jdk-23 JConsole can connect to an older JDK and show the MBean tab OK.)

@kevinjwalls I assume the RN for the removal of the subject delegation feature will need to be adjusted once this current PR is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2119907523

From kevinw at openjdk.org  Mon May 20 14:22:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 20 May 2024 14:22:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <jcyfUO8V1MK3ils-YDSuUWtFa8nD4GnFpwkmIKrBgWI=.fe185603-62a5-42f8-87cf-9d2e0d26e8a3@github.com>
 <kw5VnAja5daZCdNsMwjM-VSRDZbWAiUj9KU5ThPNlVI=.5f4d475a-e5e3-4a7f-89fe-e1860ae15368@github.com>
 <WlplzeZo4Bz3tpSsL2miQZfllBcNI9460QF-CHl0-Vw=.22a5f37a-e554-4f7c-99ed-d6f09b3b5218@github.com>
 <dXWipkZplShBsMArwj_prH57mhoIDqmkrkzR6Urb9lE=.82399b4b-435b-42f6-8200-eeb6e0f9f3a7@github.com>
Message-ID: <n5W4f3SzxVpghMXf3YRM1vaS8-jaHcbcMMTCNd9vR_g=.d43817ac-eca5-45e8-adb5-a180e0040845@github.com>

On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> > ...Is there any way to run jconsole in a way that would result in it passing a non-empty delegationSubjects, resulting in this issue still reproducing?
>>> 
>>> I don't think there is, JConsole has a hard null in this call. Also I don't see in JConsole any calls of getMBeanServerConnection with a Subject being passed, that's the main gateway method to use the removed feature.
>>> 
>>> If there was a way to use Subject Delegation with JConsole (or with anything else), and you try to attach to a jdk-23, then that will fail with the UnsupportedOperationException and that's what we want as the feature is gone. Realistically it's a feature with no known usage as discussed in the deprecation and removal changes.
>> 
>> If jconsole is passing null, why is it triggering this exception?
>
>> If jconsole is passing null, why is it triggering this exception?
> 
> JConsole passes null, but when running on an older jdk, the older RMIConnector actually "promotes" it to an array before making the remote call.  If you connect to a jdk-23 with the removal, the exception is thrown.
> 
> (JConsole running on jdk-23 can connect to jdk-23 fine.)
> (Also just to note, a jdk-23 JConsole can connect to an older JDK and show the MBean tab OK.)

> @kevinjwalls I assume the RN for the removal of the subject delegation feature will need to be adjusted once this current PR is integrated.

When this fix goes in, there will be a window of builds between jdk 23+18 to jdk-23+build_with_this_fix, where older JMX clients using addNotificationListener() will see an exception.  I wasn't going to highlight this in the RN, I thought JDK-8332303 looks quite discoverable already.  If the RN is the place to discuss temporary and now-fixed issues with selection of earlier builds before release, I could add something there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2120560237

From prr at openjdk.org  Mon May 20 18:50:04 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 May 2024 18:50:04 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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

Have you looked into / thought about how this will work for jpackaged apps ?
I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options.
Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.

-------------

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

From prr at openjdk.org  Mon May 20 18:50:06 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 May 2024 18:50:06 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
Message-ID: <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>

On Mon, 13 May 2024 10:49:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> make/conf/module-loader-map.conf line 105:
> 
>> 103:     java.smartcardio \
>> 104:     jdk.accessibility \
>> 105:     jdk.attach \
> 
> The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.

Should I understand this list to be the set of modules exempt from needing to specific that native access is allowed ?
ie they always have native access without any warnings, and further that any attempt to enable warnings, or to disable native access for these modules is ignored ?

> src/java.desktop/macosx/classes/com/apple/eio/FileManager.java line 61:
> 
>> 59:     }
>> 60: 
>> 61:     @SuppressWarnings({"removal", "restricted"})
> 
> There are several of these changes. One option might have been to just disable restricted warnings when building. But on a deeper look, I realized that in all these places we already disabled deprecation warnings for the use of security manager, so I also added a new suppression instead.

Sounds reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607136237
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607136808

From alanb at openjdk.org  Mon May 20 18:54:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 18:54:05 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
 <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>
Message-ID: <nFi5XR2qKdd2WstJE4gWSS3UGpk7uOvK4Gn7x0wArIs=.8e22fd11-0e2d-4328-81eb-81bf129ea65d@github.com>

On Mon, 20 May 2024 18:39:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/conf/module-loader-map.conf line 105:
>> 
>>> 103:     java.smartcardio \
>>> 104:     jdk.accessibility \
>>> 105:     jdk.attach \
>> 
>> The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.
>
> Should I understand this list to be the set of modules exempt from needing to specific that native access is allowed ?
> ie they always have native access without any warnings, and further that any attempt to enable warnings, or to disable native access for these modules is ignored ?

Yes, this was added via JDK-8327218. The changes in this PR are just trimming down the list to only the modules that have native code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607147983

From alanb at openjdk.org  Tue May 21 07:23:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 May 2024 07:23:07 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
Message-ID: <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>

On Mon, 20 May 2024 18:47:35 GMT, Phil Race <prr at openjdk.org> wrote:

> Have you looked into / thought about how this will work for jpackaged apps ? I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options. Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.

I don't see any tests in test/jdk/tools/jpackage that creates an application that uses JNI code. Seems like a good idea to add this via another PR and it specify --java-options so that the application launcher enables native access. It could test jpackage using jlink too.

-------------

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

From mcimadamore at openjdk.org  Tue May 21 08:47:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 May 2024 08:47:05 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
 <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
Message-ID: <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>

On Tue, 21 May 2024 07:20:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Have you looked into / thought about how this will work for jpackaged apps ? I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options. Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.
> 
> I don't see any tests in test/jdk/tools/jpackage that creates an application that uses JNI code. Seems like a good idea to add this via another PR and it specify --java-options so that the application launcher enables native access. It could test jpackage using jlink too.

These are all good suggestions. I have not looked into jpackage, but yes, I would expect that the jpackage user would need to provide extra options when packaging the application. The same is true for creating JDK image jlink (which we use in the jextract build) - although, in that case the end user also has the possibility to pass options on the command line.

-------------

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

From asemenyuk at openjdk.org  Tue May 21 15:57:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 21 May 2024 15:57:06 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <Z4v5RDWq81-UKvhkRVYPggJwn6H10GkMrmtTXhfmfkU=.5644db12-51a7-4b98-8923-04e5912d15cf@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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

`jdk.jpackage` changes look good

-------------

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

From prr at openjdk.org  Tue May 21 16:45:06 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 May 2024 16:45:06 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <2sHuToXAXHYrqtE31r7-wDvJ3JM0nQYujuLFAtqWQQI=.3c61631b-ecb1-4073-9b5f-6a379ab614cf@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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

client parts look fine.

-------------

Marked as reviewed by prr (Reviewer).

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

From asemenyuk at openjdk.org  Tue May 21 16:59:04 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 21 May 2024 16:59:04 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
 <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
 <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>
Message-ID: <xZ1AEmH_qkn4fErnw7SyycG07-_XN0Sr0OdvCPGEaQQ=.358a6210-b5a3-4b3e-a15f-bd89aa212f42@github.com>

On Tue, 21 May 2024 08:44:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> These are all good suggestions. I have not looked into jpackage, but yes, I would expect that the jpackage user would need to provide extra options when packaging the application.

It would be good to document how jpackage users packaging apps with native access will be affected by this change. Primarily that they need to pass `--illegal-native-access` parameter to affected jpackage app launchers.

-------------

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

From ihse at openjdk.org  Wed May 22 08:59:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 08:59:03 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <y3fQHNtP45EGmJmrVWNT1SMBgNP6GgYvHGM4v0Hz2h0=.ba07a68b-ea4b-4620-9e0f-70a413d0b002@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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

Build changes look good. Thanks for trimming down NATIVE_ACCESS_MODULES.

-------------

Marked as reviewed by ihse (Reviewer).

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

From kcr at openjdk.org  Wed May 22 21:45:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 May 2024 21:45:10 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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

From alanb at openjdk.org  Thu May 23 06:23:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 06:23:04 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
Message-ID: <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>

On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth <kcr at openjdk.org> 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.

-------------

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

From kcr at openjdk.org  Thu May 23 14:00:14 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 May 2024 14:00:14 GMT
Subject: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict
 the Use of JNI [v8]
In-Reply-To: <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
 <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>
Message-ID: <nbhSCeRioIjK1ko19ohj2andX49zn9W9hqj5E1dWOI0=.3bd6f07a-0df5-42b8-aed2-44a3127b85c5@github.com>

On Thu, 23 May 2024 06:20:51 GMT, Alan Bateman <alanb at openjdk.org> 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

From cjplummer at openjdk.org  Fri May 24 15:53:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 15:53:07 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
Message-ID: <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>

On Fri, 17 May 2024 10:35:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add an 'also'
>>  - typo
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 961:
> 
>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
>> 960:      * array is also accepted for compatibility reasons, which must not
>> 961:      * contain any non-null entries.
> 
> The wording is bit unusual for a parameter description. Just wondering if might be clearer to say "null or an array of null elements" and put add an `@apiNote` to explain that it allows an array with null elements for compatibility reasons. What you have is okay too course, I'm just trying to think of another way to present this odd case.

How about "must be null or an array of all null entries". You could still have an `@apiNote` explaining why.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613693492

From kevinw at openjdk.org  Fri May 24 16:46:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 16:46:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
 <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
Message-ID: <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>

On Fri, 24 May 2024 15:50:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 961:
>> 
>>> 959:      * @param delegationSubjects should be {@code null}, but a non-null
>>> 960:      * array is also accepted for compatibility reasons, which must not
>>> 961:      * contain any non-null entries.
>> 
>> The wording is bit unusual for a parameter description. Just wondering if might be clearer to say "null or an array of null elements" and put add an `@apiNote` to explain that it allows an array with null elements for compatibility reasons. What you have is okay too course, I'm just trying to think of another way to present this odd case.
>
> How about "must be null or an array of all null entries". You could still have an `@apiNote` explaining why.

Thanks, appreciate the effort trying to make it perfect.  
Can't quite say "must be null or an array of all null entries" ..because I suppose it could be an empty array.

In reality, the only caller is our code that wraps a null Subject value, in an array, so it's generally a single null in an array.  

I hope we are OK sticking with "which must not contain any non-null entries" as that does cover it (and implicitly does tell you an empty array is fine).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613758498

From cjplummer at openjdk.org  Fri May 24 16:52:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 16:52:02 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
 <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
 <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>
Message-ID: <uh9fSGiJJmA-A-WfM7z3QjLbRxDJXDrEPIKdLxvYBjo=.ecea0881-436d-475d-8d6b-5e326474a050@github.com>

On Fri, 24 May 2024 16:43:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> How about "must be null or an array of all null entries". You could still have an `@apiNote` explaining why.
>
> Thanks, appreciate the effort trying to make it perfect.  
> Can't quite say "must be null or an array of all null entries" ..because I suppose it could be an empty array.
> 
> In reality, the only caller is our code that wraps a null Subject value, in an array, so it's generally a single null in an array.  
> 
> I hope we are OK sticking with "which must not contain any non-null entries" as that does cover it (and implicitly does tell you an empty array is fine).

For me the main hold up is using "should". Maybe:

"Must be null or an array that doesn't contain any non-null entries."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613765813

From kevinw at openjdk.org  Fri May 24 17:08:01 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 17:08:01 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v3]
In-Reply-To: <uh9fSGiJJmA-A-WfM7z3QjLbRxDJXDrEPIKdLxvYBjo=.ecea0881-436d-475d-8d6b-5e326474a050@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <61dqXkH584QuYCuP-rneDFoMn2gpttpuZklABOlTDgg=.7994009d-dc44-43c2-9a6d-1ff1eb96eae3@github.com>
 <KVK0Te3m8Ijb4UQAsL2LPosnjKbvMqZnLWvuWae15LQ=.1d7bda9b-3202-4333-b3f6-e2f96909a963@github.com>
 <_GjLyh5CykenZNgYMgUIpf7S0urWQKr86j5JR56fRgE=.6a95fca7-abae-46e3-8f1f-b52c13540b15@github.com>
 <ik54rTodT7-A3pNJBxwftYyc33pUeT0MxruhKWhJgQw=.8d272776-bbd0-4bfa-82d3-10d24e1a6963@github.com>
 <uh9fSGiJJmA-A-WfM7z3QjLbRxDJXDrEPIKdLxvYBjo=.ecea0881-436d-475d-8d6b-5e326474a050@github.com>
Message-ID: <AbC_NLgPFbULTaHLQwZ_vSwpmDISEdhjfYOdesRwOGc=.dd7de88d-38d8-456c-82f4-9cded5567b7d@github.com>

On Fri, 24 May 2024 16:49:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thanks, appreciate the effort trying to make it perfect.  
>> Can't quite say "must be null or an array of all null entries" ..because I suppose it could be an empty array.
>> 
>> In reality, the only caller is our code that wraps a null Subject value, in an array, so it's generally a single null in an array.  
>> 
>> I hope we are OK sticking with "which must not contain any non-null entries" as that does cover it (and implicitly does tell you an empty array is fine).
>
> For me the main hold up is using "should". Maybe:
> 
> "Must be null or an array that doesn't contain any non-null entries."

OK I think I can get rid of "should"....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613782613

From kevinw at openjdk.org  Fri May 24 17:15:31 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 17:15:31 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v5]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  remove should... from delegationSubjects param

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/4e8f84ec..646a0d96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19253/head:pull/19253

PR: https://git.openjdk.org/jdk/pull/19253

From cjplummer at openjdk.org  Fri May 24 18:08:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 18:08:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v5]
In-Reply-To: <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>
Message-ID: <a5jCITqMhqtw5Nu08h-btoj16PiCjGWcmObgSDd5BkY=.3889512d-282b-4235-92ad-e6e0c5fc16ad@github.com>

On Fri, 24 May 2024 17:15:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove should... from delegationSubjects param

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 978:

> 976:      * @throws IOException if a general communication exception occurred.
> 977:      * @throws UnsupportedOperationException if {@code delegationSubjects}
> 978:      * is non-null and contains any non-null values.

Minor consistency issue. For the `delegationSubjects` comment above, you refer to "non-null entries". Here you refer to "non-null values". I don't have a preference on which you use, but they should be the same in both cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613843199

From kevinw at openjdk.org  Fri May 24 18:22:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 18:22:18 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v6]
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  entries consistency in param and throws text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19253/files
  - new: https://git.openjdk.org/jdk/pull/19253/files/646a0d96..0b0164e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19253&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19253/head:pull/19253

PR: https://git.openjdk.org/jdk/pull/19253

From kevinw at openjdk.org  Fri May 24 18:22:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 18:22:18 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v5]
In-Reply-To: <a5jCITqMhqtw5Nu08h-btoj16PiCjGWcmObgSDd5BkY=.3889512d-282b-4235-92ad-e6e0c5fc16ad@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <bHwkHilyGtOzqMUavQQuq5NL6uxrUc02HlvjzCDK71g=.717ebf55-0532-4552-8dfd-d864595d8d08@github.com>
 <a5jCITqMhqtw5Nu08h-btoj16PiCjGWcmObgSDd5BkY=.3889512d-282b-4235-92ad-e6e0c5fc16ad@github.com>
Message-ID: <DTENmbPnUQBOCkdE7ir6m3AM93sBwLSxP9PrHA1boqQ=.14149f49-0a8a-4ec6-b00a-6599c0274842@github.com>

On Fri, 24 May 2024 18:04:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove should... from delegationSubjects param
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 978:
> 
>> 976:      * @throws IOException if a general communication exception occurred.
>> 977:      * @throws UnsupportedOperationException if {@code delegationSubjects}
>> 978:      * is non-null and contains any non-null values.
> 
> Minor consistency issue. For the `delegationSubjects` comment above, you refer to "non-null entries". Here you refer to "non-null values". I don't have a preference on which you use, but they should be the same in both cases.

OK I'll change the "values" in the throws clause to be "entries", to be consistent, to keep this moving...
(But I don't think there was any possible confusion here. 8-) )

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1613856276

From cjplummer at openjdk.org  Fri May 24 18:58:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 May 2024 18:58:02 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v6]
In-Reply-To: <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
Message-ID: <m6nuG1Bi6Pcf1o09V8WPfXlUm1wSYwPHXiCp1yHOFN8=.776f6128-219f-4764-87ee-88e88c652909@github.com>

On Fri, 24 May 2024 18:22:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   entries consistency in param and throws text

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19253#pullrequestreview-2077642914

From kevinw at openjdk.org  Fri May 24 19:19:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 19:19:03 GMT
Subject: jmx-dev RFR: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation [v6]
In-Reply-To: <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
 <Kbaqbu627oWe9AOf_NzzRPgN2usuLW-sqmUV8k3WpgE=.95f42cc4-0ac9-4701-b423-466fc79cd8f8@github.com>
Message-ID: <eyZHzPodLy7CsqdWV1Szu3UqA_R_UOtbki7XdllC0b4=.e0bfca36-450f-48b5-8de7-4c6e078c9a64@github.com>

On Fri, 24 May 2024 18:22:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
>> 
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
>> 
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   entries consistency in param and throws text

Thanks Chris, and Daniel, for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19253#issuecomment-2130210171

From kevinw at openjdk.org  Fri May 24 19:34:07 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 May 2024 19:34:07 GMT
Subject: jmx-dev Integrated: 8332303: Better JMX interoperability with older
 JDKs, after removing Subject Delegation
In-Reply-To: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
References: <itQL1g0FVRQXPJE8LH7Jjq7bMmxvNdlUyJufBMo2xq0=.6904a82f-80ed-4a98-8728-4817a039c972@github.com>
Message-ID: <z9z-_Ki_J7XJRFiPNVDWzrK1m2MuIdNnsIWwOOpQLvc=.9537b1cd-891f-4450-85cf-c4be6bf55000@github.com>

On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Running JConsole from a previous JDK, and attaching to jdk-23 (after [JDK-8326666](https://bugs.openjdk.org/browse/JDK-8326666): Remove the Java Management Extension (JMX) Subject Delegation feature), the MBean tab is blank.
> 
> In javax/management/remote/rmi/RMIConnectionImpl.java:
> addNotificationListener rejects a non-null delegationSubjects array, but older JDKs will send such an array. It could accept the array, and only reject/throw if it contains a non-null Subject (i.e. if an attempt to use subject delegation is really happening).
> 
> Manually testing JConsole, the MBean tab is fully populated and usable.

This pull request has now been integrated.

Changeset: 253508b0
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/253508b03a3de4dab00ed7fb57e9f345d8aed1a4
Stats:     19 lines in 2 files changed: 8 ins; 3 del; 8 mod

8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation

Reviewed-by: dfuchs, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/19253