Re: jmx-dev RFR: 8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation [v3]
On Fri, 17 May 2024 10:14:43 GMT, Daniel Fuchs 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
Re: jmx-dev RFR: 8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation [v4]
> Running JConsole from a previous JDK, and attaching to jdk-23 (after > [JDK-832](https://bugs.openjdk.org/browse/JDK-832): 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=19253=03 - incr: https://webrevs.openjdk.org/?repo=jdk=19253=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
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]
> 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=19213=07 - incr: https://webrevs.openjdk.org/?repo=jdk=19213=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
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 18:39:57 GMT, Alan Bateman 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
Re: jmx-dev RFR: 8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation [v3]
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): 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
Re: jmx-dev RFR: 8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation [v3]
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): 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
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 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
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 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
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > 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
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 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 illegal.
> 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
