From kevinw at openjdk.org  Fri Mar  1 09:44:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 09:44:18 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension (JMX)
 Subject Delegation feature
Message-ID: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>

The deprecated Subject Delegation feature in JMX will be removed.

This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

Commit messages:
 - JMXConnector to throw UnsupportedOperationException
 - RMIConnectionImpl to throw when RMI calls invoke with delegatedSubject.  Removal of SubjectDelegator class.
 - Use default method.
 - Remove delegationSubject from private class RemoteMBeanServerConnection
 - 8326666: Remove the Java Management Extension (JMX) Subject Delegation feature

Changes: https://git.openjdk.org/jdk/pull/18025/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326666
  Stats: 1642 lines in 29 files changed: 18 ins; 1547 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Fri Mar  1 09:44:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 09:44:18 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <Kn3IGHIVy5uhHscpa63rRJsv9GnuVdD2md_IvWjcs10=.e56720f5-3288-4326-9b21-0984a5095933@github.com>

On Tue, 27 Feb 2024 10:44:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

This covers the public interface to the feature, and tests.

Locally the feature is refused during a call to getMBeanServerConnection(with a non-null delegationSubject).

Remotely, `javax.management.remote.rmi.RMIConnectionImpl` has methods which accept a Subject parameter for Subject Delegation.  This cannot now be non-null in local usage, but an RMI Connection from an older JDK can invoke these methods with a non-null delegationSubject.  Such access will be recognised and an UnsupportedOperationException will be thrown (which the client will see).

RMIConnectionImpl can be simplified, and the class SubjectDelegator removed.

JMXSubjectDomainCombiner I would like to remove separately after this is done.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1972845693

From dnsimon at openjdk.org  Fri Mar  1 17:28:12 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 1 Mar 2024 17:28:12 GMT
Subject: jmx-dev RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 fails on libgraal
Message-ID: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>

To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
With this change, the test now reliably passes.

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

Commit messages:
 - adjust timeout in NotifReconnectDeadlockTest.java

Changes: https://git.openjdk.org/jdk/pull/18085/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18085&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327136
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18085/head:pull/18085

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

From never at openjdk.org  Fri Mar  1 18:00:53 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 1 Mar 2024 18:00:53 GMT
Subject: jmx-dev RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 fails on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <pTleWEVysb5lBj6Bl6ETg_aXPEwDatFMUrJre6aVuao=.2fd589bd-71ec-4fc7-9c8e-a72f870b65c6@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

Looks good

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18085#pullrequestreview-1911730736

From kevinw at openjdk.org  Fri Mar  1 18:31:42 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 18:31:42 GMT
Subject: jmx-dev RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 fails on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <vovpAubRjPcGR0xK_f_HY_MzrvTlxSTHc5539OGa0tc=.ca0b7431-dceb-4166-9635-7b949087f92b@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

Sounds good.

One day, somebody among us will implement timeouts that take into account whether there are JVM options like -Xcomp or other factors that slow things down... 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18085#pullrequestreview-1911784742

From dnsimon at openjdk.org  Fri Mar  1 18:56:58 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 1 Mar 2024 18:56:58 GMT
Subject: jmx-dev RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 fails on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <r-AW1KL6Yf66qMLnBfc8lmtK-n107GC28XPZGlHgy7M=.9548732d-654d-4ea5-998c-80a18ff879e1@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18085#issuecomment-1973749075

From dnsimon at openjdk.org  Fri Mar  1 18:56:59 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 1 Mar 2024 18:56:59 GMT
Subject: jmx-dev Integrated: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java
 fails on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <gbVrc_z7KIwt7pA6klCeVMeLQFrsrjzOn4UlfU0RrXQ=.c2200bdd-19a4-477c-bba2-00a9ebd7f7d0@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

This pull request has now been integrated.

Changeset: 8f0fb27d
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f0fb27decec28f32e4d88341237189ba4a340fb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8327136: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails on libgraal

Reviewed-by: never, kevinw

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

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

From kevinw at openjdk.org  Mon Mar  4 13:24:05 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 13:24:05 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v2]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  RMIConnection comments update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/f236ae82..8635a3a5

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

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

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

From alanb at openjdk.org  Mon Mar  4 13:40:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Mar 2024 13:40:54 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v2]
In-Reply-To: <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
Message-ID: <JJwyAQmjrcxUN1FL8ZM_WZQ5jZdzkr412aleNBKBojU=.d277359c-c9a0-4e5f-9813-f68dea38239d@github.com>

On Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RMIConnection comments update

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

> 124:      * @param className The class name of the MBean to be instantiated.
> 125:      * @param name The object name of the MBean. May be null.
> 126:      * @param delegationSubject No longer supported and should be null.

I think this interface will require all methods that take a delegation subject to specify UOE then the subject is not null. Yes, this will invalidate implementations that are outside of the JDK but such implementations need to be updated anyway.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:

> 156:      */
> 157:     @Deprecated(since="21", forRemoval=true)
> 158:     public default MBeanServerConnection getMBeanServerConnection(Subject delegationSubject)

Specifying the UOE in the param description is problematic. I think you want to specify delegationSubject as not used, must be null, then declare UOE as one of the exceptions thrown by the method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511174715
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511172106

From mullan at openjdk.org  Mon Mar  4 15:18:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:18:59 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:

> 67:         }
> 68:         private void setPrincipal() {
> 69:             Subject subject = Subject.current();

Why change this to `Subject.current()` if you are requiring the SM to be allowed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511332276

From dfuchs at openjdk.org  Mon Mar  4 15:29:43 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 4 Mar 2024 15:29:43 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v2]
In-Reply-To: <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
Message-ID: <LfV7zu4_5MpbJ6Q3X04U7NIucsbNr_DHjnD7qXJReBs=.2fddb025-3945-4158-b17c-eda62770802d@github.com>

On Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RMIConnection comments update

In addition to Alan's remarks I believe we need new tests to verify the new behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1976841428

From mullan at openjdk.org  Mon Mar  4 15:30:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:30:46 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:

> 307:         final Subject s;
> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
> 309:             s = Subject.current();

We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511351340

From mullan at openjdk.org  Mon Mar  4 15:35:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:35:48 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <2ScdK8KcKlERkLJo7THfkI6UloVwIfWKn-sWF7ZzJsg=.5634f7e1-a6c2-4b19-9829-2fb1129a65c9@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:

> 281:     static void readFile(String filename) {
> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
> 283:         Subject subject = Subject.current();

Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511358336

From kevinw at openjdk.org  Mon Mar  4 16:00:57 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 16:00:57 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v3]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <2yxssx9fcD6B3QJSm4fwZ0wHoyq8aLFUIe-p-HscZMM=.08f5c471-9cd9-4ddb-9f3c-013e5adf95f0@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

 - Update doc comments for RMIConnection.  Additional throw for delegationSubjects array.
 - JMXConnector.getMBeanServer(ds) doc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/8635a3a5..c607b69a

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

  Stats: 102 lines in 3 files changed: 53 ins; 1 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Mon Mar  4 16:05:59 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 16:05:59 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v2]
In-Reply-To: <JJwyAQmjrcxUN1FL8ZM_WZQ5jZdzkr412aleNBKBojU=.d277359c-c9a0-4e5f-9813-f68dea38239d@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
 <JJwyAQmjrcxUN1FL8ZM_WZQ5jZdzkr412aleNBKBojU=.d277359c-c9a0-4e5f-9813-f68dea38239d@github.com>
Message-ID: <LMrfAnzKlNal1uUricpfcovEpzAeWJJP5VytTs2PPiI=.060060eb-f7df-4f62-918a-11173cdd25b2@github.com>

On Mon, 4 Mar 2024 13:37:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RMIConnection comments update
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:
> 
>> 124:      * @param className The class name of the MBean to be instantiated.
>> 125:      * @param name The object name of the MBean. May be null.
>> 126:      * @param delegationSubject No longer supported and should be null.
> 
> I think this interface will require all methods that take a delegation subject to specify UOE when the subject is not null. Yes, this will invalidate implementations that are outside of the JDK but such implementations need to be updated anyway.

Yes, updated.

> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:
> 
>> 156:      */
>> 157:     @Deprecated(since="21", forRemoval=true)
>> 158:     public default MBeanServerConnection getMBeanServerConnection(Subject delegationSubject)
> 
> Specifying the UOE in the param description is problematic. I think you want to specify delegationSubject as not used, must be null, then declare UOE as one of the exceptions thrown by the method.

Thanks,  updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511402928
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511401561

From mullan at openjdk.org  Mon Mar  4 16:22:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 16:22:51 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>

On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.base/share/classes/javax/security/auth/Subject.java line 112:

> 110:  *
> 111:  * <p><b><a id="sm-allowed">These methods behave differently depending on
> 112:  * whether a security manager is allowed or disallowed</a></b>:

Suggest linking "a security manager is allowed or disallowed" to `SecurityManager.html#set-security-manager`.

src/java.base/share/classes/javax/security/auth/Subject.java line 120:

> 118:  * {@code getSubject(AccessControlContext)} method.
> 119: *  <li>If a security manager is not allowed, which means it
> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set

I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:

> 25:  * @test
> 26:  * @bug 8296244
> 27:  * @enablePreview

Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

test/jdk/javax/security/auth/Subject/Compat.java line 34:

> 32: /*
> 33:  * @test
> 34:  * @run main/othervm -Djava.security.manager=allow Compat

Missing `@summary` and `@bug`.

test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:

> 57: 
> 58:         // TODO: Still has no way to reject the following code.
> 59:         // Here, AccessController::getContext returns a plan ACC without

typo: s/plan/plain/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511419716
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511424024
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511380094
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511393254
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511366395

From weijun at openjdk.org  Mon Mar  4 19:54:45 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 19:54:45 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
Message-ID: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>

On Mon, 4 Mar 2024 15:28:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
> 
>> 307:         final Subject s;
>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>> 309:             s = Subject.current();
> 
> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511716084

From mullan at openjdk.org  Mon Mar  4 19:59:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 19:59:46 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
Message-ID: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>

On Mon, 4 Mar 2024 19:51:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
>> 
>>> 307:         final Subject s;
>>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>>> 309:             s = Subject.current();
>> 
>> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.
>
> I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

I think we need @kevinjwalls or @dfuch to help advise on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511721920

From weijun at openjdk.org  Mon Mar  4 20:33:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:33:54 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
Message-ID: <e65Omm5EaxnZ_Q4ymvpwK0kafK6AWDhLAJDUqPzhEvc=.a8badc5d-0ce1-4302-94bc-f03e9920326d@github.com>

On Mon, 4 Mar 2024 15:15:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:
> 
>> 67:         }
>> 68:         private void setPrincipal() {
>> 69:             Subject subject = Subject.current();
> 
> Why change this to `Subject.current()` if you are requiring the SM to be allowed?

When SM is allowed, `Subject.current()` is equivalent to `Subject.getSubject(AccessController.getContext())`. I can revert the change.

> test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:
> 
>> 57: 
>> 58:         // TODO: Still has no way to reject the following code.
>> 59:         // Here, AccessController::getContext returns a plan ACC without
> 
> typo: s/plan/plain/

Yes.

> test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:
> 
>> 281:     static void readFile(String filename) {
>> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
>> 283:         Subject subject = Subject.current();
> 
> Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

Yes, we can.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755373
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511756265
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755860

From weijun at openjdk.org  Mon Mar  4 20:39:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:39:54 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <AWOnbHXGoCGZKp0Ecva-eQU-Yf9hn6mdPmp1qVThatU=.dfb9494c-31fb-410b-bab5-d27e314144eb@github.com>

On Mon, 4 Mar 2024 15:47:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8296244
>> 27:  * @enablePreview
> 
> Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

OK.

> test/jdk/javax/security/auth/Subject/Compat.java line 34:
> 
>> 32: /*
>> 33:  * @test
>> 34:  * @run main/othervm -Djava.security.manager=allow Compat
> 
> Missing `@summary` and `@bug`.

Will Add.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511760021
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511761591

From weijun at openjdk.org  Mon Mar  4 20:49:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:49:54 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <xQbhbPkhHusDyyQ8zlwv0Xr3CZvYyP5aKVWOR4llj4s=.9bcccc3f-b7c7-4b59-b7b9-b8bd2427af9e@github.com>

On Mon, 4 Mar 2024 16:17:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 120:
> 
>> 118:  * {@code getSubject(AccessControlContext)} method.
>> 119: *  <li>If a security manager is not allowed, which means it
>> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set
> 
> I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511771517

From weijun at openjdk.org  Mon Mar  4 21:54:13 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 21:54:13 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv4=5D?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9_c9PpQBHzo6FdR5aaSQ_qCCwrd2yGr1CNsGdj6HDjk=.84620353-2d09-4599-8a05-b3b2f08ab855@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  revert some test changes, spec change for subject

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/8f270d09..e57f7250

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

  Stats: 44 lines in 6 files changed: 18 ins; 3 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From kevinw at openjdk.org  Tue Mar  5 11:39:48 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 11:39:48 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
Message-ID: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>

On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I was not exactly sure if we will support this functionality when there is no SM. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.
>
> I think we need @kevinjwalls or @dfuch to help advise on this.

Right, this does not depend on the SM.   All we need to do is get the Subject.
This method implements the basic monitor (readonly) and control (readwrite) access.
accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512676642

From weijun at openjdk.org  Tue Mar  5 14:46:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:46:47 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
Message-ID: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>

On Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I think we need @kevinjwalls or @dfuch to help advise on this.
>
> Right, this does not depend on the SM.   All we need to do is get the Subject.
> This method implements the basic monitor (readonly) and control (readwrite) access.
> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512951092

From weijun at openjdk.org  Tue Mar  5 14:58:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:58:25 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv5=5D?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <5fLmCMsDfb6akv1964_z9y8a4ccxmXaLJVjNiU5Khvs=.69025b5e-374e-4ae2-9db8-d27580a10345@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - the patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/e57f7250..2b55b171

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

  Stats: 97308 lines in 3235 files changed: 46912 ins; 26097 del; 24299 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From kevinw at openjdk.org  Tue Mar  5 16:51:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 16:51:46 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
Message-ID: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>

On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Right, this does not depend on the SM.   All we need to do is get the Subject.
>> This method implements the basic monitor (readonly) and control (readwrite) access.
>> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.
>
> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

(That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
https://github.com/openjdk/jdk/pull/18025 )

makeClient in RMIJRMPServerImpl creates RMIConnectionImpl

..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513164360

From weijun at openjdk.org  Tue Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv6=5D?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  revert changes to MBeanServerFileAccessController.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/2b55b171..80810b54

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

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

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

From weijun at openjdk.org  Tue Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
Message-ID: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>

On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.
>
> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
> 
> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
> https://github.com/openjdk/jdk/pull/18025 )
> 
> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
> 
> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.

I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.

Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513410552

From kevinw at openjdk.org  Wed Mar  6 11:42:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Mar 2024 11:42:18 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v4]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <qEdJCGr1AJ87uEfYrRMVws2D-H1_2CNMhTLKdjt-HuQ=.678ceb67-61fd-419f-8425-39cc318f1483@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Test that SubjectDelegation is refused.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/c607b69a..19ace691

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

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

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

From kevinw at openjdk.org  Wed Mar  6 11:46:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Mar 2024 11:46:16 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Test specifically that UOE is thrown.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/19ace691..c5256c3f

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

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

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

From kevinw at openjdk.org  Wed Mar  6 11:46:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Mar 2024 11:46:16 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v4]
In-Reply-To: <qEdJCGr1AJ87uEfYrRMVws2D-H1_2CNMhTLKdjt-HuQ=.678ceb67-61fd-419f-8425-39cc318f1483@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <qEdJCGr1AJ87uEfYrRMVws2D-H1_2CNMhTLKdjt-HuQ=.678ceb67-61fd-419f-8425-39cc318f1483@github.com>
Message-ID: <mM7_KUEuTf9wJBwCPIrHOCAE9u1iaT1QqxM7-xLICKQ=.68403f6d-2669-4a75-8c67-0ce0ae9faf14@github.com>

On Wed, 6 Mar 2024 11:42:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test that SubjectDelegation is refused.

Added a test to ensure  jmxc.getMBeanServerConnection(delegationSubject) throws UnsupportedOperationException.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1980688614

From dfuchs at openjdk.org  Thu Mar  7 10:12:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 7 Mar 2024 10:12:55 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv3=5D?=
In-Reply-To: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
 <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
Message-ID: <o903TWvm-n5rqeKURwyNYxtab9UPMSrTwyMUgLWBk-A=.31cb42ae-4aa2-43fc-bb4e-27b00b6ba891@github.com>

On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> 
>> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
>> https://github.com/openjdk/jdk/pull/18025 )
>> 
>> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
>> 
>> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.
>
> I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.
> 
> I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.
> 
> Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

Yes - the JMX implementation stores and retrieve subjects in the AccessControlContext and then uses doPrivileged. Subject.doAs is not used in the JMX implementation.

There are two different uses of Subject in JMX: 

1. one is a simplified role-based authentication/authorization at the default agent level. 
2. The other one is a permission check where different subjects can be granted different privileges in the policy file. 

The latter will go away since the SM is going away, but needs to be preserved until then.
The former we want to keep and needs to keep working (by changing the code to use callAs) even after the SM is gone.

Subject delegation allows an authenticated subject (1. above) to perform actions on behalf of a delegation subject, where the privileged granted by 2. are the intersection of the privileges of the two subjects.
@kevinjwalls is currently working on removing subject delegation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1515896397

From mullan at openjdk.org  Thu Mar  7 20:00:52 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Mar 2024 20:00:52 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
Message-ID: <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>

On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test specifically that UOE is thrown.

Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1984324717

From mullan at openjdk.org  Thu Mar  7 20:04:56 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Mar 2024 20:04:56 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
Message-ID: <HelxRioowIY-SM3wJQ2aZR7znw3qkVOqM59Ph45zZcw=.4c210e57-4808-44fc-880d-128649f49406@github.com>

On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test specifically that UOE is thrown.

Are there remaining tests that test the JMX fine grained permissions feature w/o depending on subject delegation?

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1984329809

From mullan at openjdk.org  Thu Mar  7 21:26:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Mar 2024 21:26:55 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
Message-ID: <bL9_pIDwNbViasMDCsl14OzxPmWTHT5-Q0dsJC48czk=.bd9083af-29bf-4f69-9575-f6e26db8e727@github.com>

On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test specifically that UOE is thrown.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 153:

> 151:      *
> 152:      * @exception UnsupportedOperationException if a non-null delegationSubject
> 153:      * is specifed. Subject Delegation has been removed.

Typo: s/specifed/specified/

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:

> 156:      * and is only useful in conjunction with other APIs which are deprecated and
> 157:      * subject to removal in a future release. Consequently, this method is also
> 158:      * deprecated and subject to removal. There is no replacement.

Maybe you want to change this text to be more direct here that subject delegation is no longer supported and what this method now does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516758560
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516761404

From kevinw at openjdk.org  Thu Mar  7 22:00:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Mar 2024 22:00:13 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v6]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

 - Clarify deprecation comment.
 - typo
 - Remove additional passing of delegatedSubject in ClientListenerInfo and ClientNotifForwarder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/c5256c3f..4beae2f2

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

  Stats: 54 lines in 5 files changed: 0 ins; 25 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Thu Mar  7 22:00:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Mar 2024 22:00:14 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <bL9_pIDwNbViasMDCsl14OzxPmWTHT5-Q0dsJC48czk=.bd9083af-29bf-4f69-9575-f6e26db8e727@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <bL9_pIDwNbViasMDCsl14OzxPmWTHT5-Q0dsJC48czk=.bd9083af-29bf-4f69-9575-f6e26db8e727@github.com>
Message-ID: <kD8e-HZecg9BYp10rEq45WNOntqqaMb0ovaNZzt171A=.a71a117f-89d2-4961-8bce-2d186063bd15@github.com>

On Thu, 7 Mar 2024 20:07:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test specifically that UOE is thrown.
>
> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 153:
> 
>> 151:      *
>> 152:      * @exception UnsupportedOperationException if a non-null delegationSubject
>> 153:      * is specifed. Subject Delegation has been removed.
> 
> Typo: s/specifed/specified/

got it thanks.

> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:
> 
>> 156:      * and is only useful in conjunction with other APIs which are deprecated and
>> 157:      * subject to removal in a future release. Consequently, this method is also
>> 158:      * deprecated and subject to removal. There is no replacement.
> 
> Maybe you want to change this text to be more direct here that subject delegation is no longer supported and what this method now does.

Yes, that should be updated, the feature is gone with this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516884990
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516885582

From kevinw at openjdk.org  Fri Mar  8 10:22:55 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 8 Mar 2024 10:22:55 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
Message-ID: <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>

On Thu, 7 Mar 2024 19:58:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.

No, nothing uses SubjectDelegationPermission.  That can be deprecated.

> Are there remaining tests that test the JMX fine grained permissions feature w/o depending on subject delegation?

Yes there are some tests other than those changed here, which use MBeanPermission in policies and become irrelevant post-SM.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1985429423

From weijun at openjdk.org  Fri Mar  8 22:07:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 22:07:03 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v6]
In-Reply-To: <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>
Message-ID: <rS5w4MROThlrUOyDhecx5MGgu9NMPJSBqzbxWJ5w9ng=.b4942665-0c60-40fb-8bbd-e84c70abaf55@github.com>

On Thu, 7 Mar 2024 22:00:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Clarify deprecation comment.
>  - typo
>  - Remove additional passing of delegatedSubject in ClientListenerInfo and ClientNotifForwarder

src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002, 2024 Oracle and/or its affiliates. All rights reserved.

Missing `,` after 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1518357791

From kevinw at openjdk.org  Mon Mar 11 10:09:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 11 Mar 2024 10:09:28 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  (C) oops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/4beae2f2..f5794c43

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

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

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

From kevinw at openjdk.org  Mon Mar 11 10:09:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 11 Mar 2024 10:09:28 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v6]
In-Reply-To: <rS5w4MROThlrUOyDhecx5MGgu9NMPJSBqzbxWJ5w9ng=.b4942665-0c60-40fb-8bbd-e84c70abaf55@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>
 <rS5w4MROThlrUOyDhecx5MGgu9NMPJSBqzbxWJ5w9ng=.b4942665-0c60-40fb-8bbd-e84c70abaf55@github.com>
Message-ID: <VXmdmfOrYPTU2BcKx1rT5Ew-CcOoXXT32baSOI7Fvi8=.7721c2af-2ebe-4e2e-a737-d69655f37b5c@github.com>

On Fri, 8 Mar 2024 22:04:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Missing `,` after 2024.

oops, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1519459149

From dfuchs at openjdk.org  Mon Mar 11 16:32:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 16:32:18 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
 <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
Message-ID: <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>

On Fri, 8 Mar 2024 10:20:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.

No issue with deprecation. I guess it can be removed once `java.security.Policy` is removed?

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1988693902

From dfuchs at openjdk.org  Mon Mar 11 17:25:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 17:25:55 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
Message-ID: <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>

On Mon, 11 Mar 2024 10:09:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C) oops

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java line 618:

> 616:                 throw new SecurityException("Subject Delegation has been removed.");
> 617:             }
> 618:         }

Can't this constructor be removed? It's a private inner class so we should be able to throw before calling that constructor?

test/jdk/javax/management/remote/mandatory/notif/DeadListenerTest.java line 78:

> 76:         cs.start();
> 77:         JMXServiceURL addr = cs.getAddress();
> 78:         assertTrue("Expected no connections in new connector server", rmiServer.connections.isEmpty());

Changes to this file seem unrelated to the removal of the feature - could you confirm that they were intended (no issue if they were intended).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520108369
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520127466

From mchung at openjdk.org  Mon Mar 11 18:05:56 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 18:05:56 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
Message-ID: <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>

On Mon, 11 Mar 2024 10:09:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C) oops

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

> 124:      * @param className The class name of the MBean to be instantiated.
> 125:      * @param name The object name of the MBean. May be null.
> 126:      * @param delegationSubject No longer supported and should be null.

I think it can be simplified to:

Suggestion:

     * @param delegationSubject must be {@code null}.


I see no need to mention this feature no longer supported as no one is using and will use this feature.

Same comment applies to all methods that take `delegationSubject`.

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

> 155:      * @throws IOException if a general communication exception occurred.
> 156:      * @throws UnsupportedOperationException if a non-null delegationSubject
> 157:      * is specified. Subject Delegation has been removed.

This can be simplified to:

Suggestion:

     * @throws UnsupportedOperationException if {@code delegationSubject} is non-null


Same comment applies to all methods that take `delegationSubject`.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 139:

> 137:     /**
> 138:      * <p>This method remains for compatibility reasons, but has no more meaning
> 139:      * than {@link #getMBeanServerConnection()}.

Suggestion:

     * <p>This method is equivalent to calling {@link #getMBeanServerConnection()}.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 142:

> 140:      *
> 141:      * @param delegationSubject must be null, since the removal of the
> 142:      * Subject Delegation feature.

Suggestion:

     * @param delegationSubject must be {@code null}

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 153:

> 151:      *
> 152:      * @exception UnsupportedOperationException if a non-null delegationSubject
> 153:      * is specified. Subject Delegation has been removed.

Suggestion:

     * @exception UnsupportedOperationException if {@code delegationSubject} is non-null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520188392
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520183154
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520165902
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520166471
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520170490

From dfuchs at openjdk.org  Mon Mar 11 18:45:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 18:45:18 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
Message-ID: <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>

On Mon, 11 Mar 2024 17:56:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:
> 
>> 124:      * @param className The class name of the MBean to be instantiated.
>> 125:      * @param name The object name of the MBean. May be null.
>> 126:      * @param delegationSubject No longer supported and should be null.
> 
> I think it can be simplified to:
> 
> Suggestion:
> 
>      * @param delegationSubject must be {@code null}.
> 
> 
> I see no need to mention this feature no longer supported as no one is using and will use this feature.
> 
> Same comment applies to all methods that take `delegationSubject`.

I was wondering if we should add a note at the class-level API documentation to say that subject delegation has been removed (or is no longer supported), and that methods will throw UOE if a non-null delegation subject is passed. It is otherwise strange to see a parameter that must be null. It could be worthwhile to mention it just once, at the class-level API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520260840

From dfuchs at openjdk.org  Mon Mar 11 18:53:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 18:53:15 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
Message-ID: <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>

On Mon, 11 Mar 2024 18:39:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:
>> 
>>> 124:      * @param className The class name of the MBean to be instantiated.
>>> 125:      * @param name The object name of the MBean. May be null.
>>> 126:      * @param delegationSubject No longer supported and should be null.
>> 
>> I think it can be simplified to:
>> 
>> Suggestion:
>> 
>>      * @param delegationSubject must be {@code null}.
>> 
>> 
>> I see no need to mention this feature no longer supported as no one is using and will use this feature.
>> 
>> Same comment applies to all methods that take `delegationSubject`.
>
> I was wondering if we should add a note at the class-level API documentation to say that subject delegation has been removed (or is no longer supported), and that methods will throw UOE if a non-null delegation subject is passed. It is otherwise strange to see a parameter that must be null. It could be worthwhile to mention it just once, at the class-level API.

Maybe mention there too that the delegationSubject parameter is kept for interoperability with older remote clients.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520271921

From mchung at openjdk.org  Mon Mar 11 19:27:13 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 19:27:13 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
 <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
Message-ID: <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>

On Mon, 11 Mar 2024 18:49:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I was wondering if we should add a note at the class-level API documentation to say that subject delegation has been removed (or is no longer supported), and that methods will throw UOE if a non-null delegation subject is passed. It is otherwise strange to see a parameter that must be null. It could be worthwhile to mention it just once, at the class-level API.
>
> Maybe mention there too that the delegationSubject parameter is kept for interoperability with older remote clients.

It's a good suggestion.   Something like this:

All methods that take a `Subject` parameter will throw UOE if called with a non-null subject delegation.  JMX subject delegation feature is no longer supported.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520310935

From mullan at openjdk.org  Mon Mar 11 21:08:13 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Mar 2024 21:08:13 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
 <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
 <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
Message-ID: <JXJhm2lXQ4NzKEGMxNarDvxrfKELy7yVhROF-gOO9I0=.aa209286-fdc2-4327-848b-b3ab498c9f83@github.com>

On Mon, 11 Mar 2024 15:19:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.
> 
> No issue with deprecation. I guess it can be removed once `java.security.Policy` is removed?

Yes, or to be more precise, when the `JavaPolicy` implementation of `java.security.Policy` is removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1989444321

From kevinw at openjdk.org  Tue Mar 12 11:25:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 11:25:16 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
Message-ID: <ICJ6vtsVloyYNwNCdUa3BEsE2kDHUrjCcs4vHV6lJSU=.cb8cf980-3f16-401b-96bf-94002a0c9395@github.com>

On Mon, 11 Mar 2024 17:22:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> test/jdk/javax/management/remote/mandatory/notif/DeadListenerTest.java line 78:
> 
>> 76:         cs.start();
>> 77:         JMXServiceURL addr = cs.getAddress();
>> 78:         assertTrue("Expected no connections in new connector server", rmiServer.connections.isEmpty());
> 
> Changes to this file seem unrelated to the removal of the feature - could you confirm that they were intended (no issue if they were intended).

Yes, they were intentional, should have made that clear.  I had a failure from this test at some point, and the assert message made no sense to me.
e.g. "New value of count1 == 1" is shown, but that's what was expected and not what was seen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521290618

From kevinw at openjdk.org  Tue Mar 12 11:52:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 11:52:33 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v8]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <Tq5M_UqTrOYCjALmd1QKMOwiHsclnmK8QdZEMkBsDTo=.fdbf79c8-e573-469c-af6c-87210374af1f@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Remove unnecessary constructor in private class
 - Merge remote-tracking branch 'upstream/master' into 8326666_SubjectDelegation_remove
 - (C) oops
 - Clarify deprecation comment.
 - typo
 - Remove additional passing of delegatedSubject in ClientListenerInfo and ClientNotifForwarder
 - Test specifically that UOE is thrown.
 - Test that SubjectDelegation is refused.
 - Update doc comments for RMIConnection.  Additional throw for delegationSubjects array.
 - JMXConnector.getMBeanServer(ds) doc update
 - ... and 6 more: https://git.openjdk.org/jdk/compare/df1aab1c...7ae77376

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/f5794c43..7ae77376

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

  Stats: 98336 lines in 2041 files changed: 16429 ins; 75917 del; 5990 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Tue Mar 12 11:52:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 11:52:34 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
Message-ID: <fprDm0QjuRxXIQ9pqwsk8XzxaHK6WzvG8IeoMhbDfMM=.ee24bf4a-440d-4e5a-bda4-804dc3fe65fd@github.com>

On Mon, 11 Mar 2024 17:10:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java line 618:
> 
>> 616:                 throw new SecurityException("Subject Delegation has been removed.");
>> 617:             }
>> 618:         }
> 
> Can't this constructor be removed? It's a private inner class so we should be able to throw before calling that constructor?

Yes that can disappear with no impact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521324287

From kevinw at openjdk.org  Tue Mar 12 15:24:17 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 15:24:17 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
Message-ID: <RvuQ-iLHMjTtlcVgv3jK88Rnd9UAHVfPCLWoNa47Tzw=.97bfbeac-88bf-4a64-83d4-f89a1d64f90f@github.com>

On Mon, 11 Mar 2024 17:49:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 139:
> 
>> 137:     /**
>> 138:      * <p>This method remains for compatibility reasons, but has no more meaning
>> 139:      * than {@link #getMBeanServerConnection()}.
> 
> Suggestion:
> 
>      * <p>This method is equivalent to calling {@link #getMBeanServerConnection()}.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521667592

From kevinw at openjdk.org  Tue Mar 12 15:41:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 15:41:18 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
 <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
 <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>
Message-ID: <IJmShi6HhRYg8D4BkP1-SD7KdJT0dMkIw0OZAPBIijA=.eeb537e6-15ca-41b2-b50c-1adbbf35dad2@github.com>

On Mon, 11 Mar 2024 19:24:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Maybe mention there too that the delegationSubject parameter is kept for interoperability with older remote clients.
>
> It's a good suggestion.   Something like this:
> 
> All methods that take a `Subject` parameter will throw UOE if called with a non-null subject delegation.  JMX subject delegation feature is no longer supported.

OK sure -- didn't want to make the individual delegationSubject mentions too terse, but if there is some earlier text then that could be OK...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521699619

From mullan at openjdk.org  Tue Mar 12 19:10:16 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Mar 2024 19:10:16 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv6=5D?=
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <leVNLEnlMOT_Q12vSYN1zBocFXWkf2eoJQrj_GYXqTs=.74126c7c-6afb-483b-98e2-f8666849c3da@github.com>

On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:

> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
> 54: 
> 55:         // Observable in the same thread in ACC mode, but not in the SV mode

Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1521991975

From kevinw at openjdk.org  Tue Mar 12 19:43:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 19:43:26 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v9]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <67d24Poc0p9A6LKZMcbuMVn6Xq7ve2hvsyEhVbwiR6U=.e0a54f63-6b91-48f0-b7dc-ddb83068cb7a@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Javadoc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/7ae77376..15717fbe

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

  Stats: 89 lines in 2 files changed: 5 ins; 33 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Tue Mar 12 19:43:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 19:43:26 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v7]
In-Reply-To: <IJmShi6HhRYg8D4BkP1-SD7KdJT0dMkIw0OZAPBIijA=.eeb537e6-15ca-41b2-b50c-1adbbf35dad2@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
 <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
 <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>
 <IJmShi6HhRYg8D4BkP1-SD7KdJT0dMkIw0OZAPBIijA=.eeb537e6-15ca-41b2-b50c-1adbbf35dad2@github.com>
Message-ID: <WX6w0AC6OuBXo3iJfG0LIZ6uPVPdRzAFZpULuY7xuRI=.66dc7225-565e-49f5-b307-7e42c77511a0@github.com>

On Tue, 12 Mar 2024 15:38:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> It's a good suggestion.   Something like this:
>> 
>> All methods that take a `Subject` parameter will throw UOE if called with a non-null subject delegation.  JMX subject delegation feature is no longer supported.
>
> OK sure -- didn't want to make the individual delegationSubject mentions too terse, but if there is some earlier text then that could be OK...

Thanks, updating with those changes. Additionally, in JMXConnector I'm removing the text "Calling this method is equivalent to calling getMBSC(null)..." as that is pointless, and possibly misleading now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1522024836

From kevinw at openjdk.org  Tue Mar 12 19:58:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 19:58:24 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v10]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/15717fbe..a3e09e90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=08-09

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

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

From mchung at openjdk.org  Wed Mar 13 17:42:15 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 13 Mar 2024 17:42:15 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v10]
In-Reply-To: <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>
Message-ID: <vyEAK9gzbLmLWj70wD_YX70BLeSYzu7gCkOwE7ZeLAg=.5ce26638-30ab-4746-bd92-ac46895b07dc@github.com>

On Tue, 12 Mar 2024 19:58:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

The spec change looks good to me.    I leave to others to review the implementation and test changes.

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

> 83:  *
> 84:  * <p>JMX Subject Delegation has been removed. All methods that take a
> 85:  * delegationSubject parameter will throw UnsupportedOperationException if

Suggestion:

 * <p>JMX Subject Delegation has been removed. All methods that take a
 * delegation subject parameter will throw {@code UnsupportedOperationException} if

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1934819628
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1523673795

From kevinw at openjdk.org  Wed Mar 13 19:15:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 13 Mar 2024 19:15:13 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v10]
In-Reply-To: <vyEAK9gzbLmLWj70wD_YX70BLeSYzu7gCkOwE7ZeLAg=.5ce26638-30ab-4746-bd92-ac46895b07dc@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>
 <vyEAK9gzbLmLWj70wD_YX70BLeSYzu7gCkOwE7ZeLAg=.5ce26638-30ab-4746-bd92-ac46895b07dc@github.com>
Message-ID: <EZMs2fRg21kV6CjhIjQV3TIKwgsMvo8sB6mkfV4E8_I=.3f99bd88-b6ca-4941-ad41-54eccb75fd66@github.com>

On Wed, 13 Mar 2024 17:39:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The spec change looks good to me. I leave to others to review the implementation and test changes.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1995445698

From mullan at openjdk.org  Wed Mar 13 20:09:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Mar 2024 20:09:09 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv6=5D?=
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>

On Tue, 5 Mar 2024 19:56:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:

> 27:  * @enablePreview
> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
> 29:  *      Need @enablePreview to use StructuredTaskScope.

jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1523838888

From dnsimon at openjdk.org  Thu Mar 14 10:51:54 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Mar 2024 10:51:54 GMT
Subject: jmx-dev RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
Message-ID: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>

This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

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

Commit messages:
 - increase timeout in loop waiting for listeners to receive notifs

Changes: https://git.openjdk.org/jdk/pull/18297/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328135
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18297/head:pull/18297

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

From kevinw at openjdk.org  Thu Mar 14 11:53:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 11:53:11 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v11]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <_QCspkFRemnLYapwCrVmuX7ePA7o1v2PB2COJfadYqw=.6b86cb4d-0614-4ce7-86f4-e1ad38a1a9bf@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

 - Clarify JMXConnector equivalence comment.
 - RMIConnectionImpl needs to explicity inherit the unchecked UOE.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/a3e09e90..418b635c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=09-10

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

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

From dfuchs at openjdk.org  Thu Mar 14 11:59:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 14 Mar 2024 11:59:40 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v11]
In-Reply-To: <_QCspkFRemnLYapwCrVmuX7ePA7o1v2PB2COJfadYqw=.6b86cb4d-0614-4ce7-86f4-e1ad38a1a9bf@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <_QCspkFRemnLYapwCrVmuX7ePA7o1v2PB2COJfadYqw=.6b86cb4d-0614-4ce7-86f4-e1ad38a1a9bf@github.com>
Message-ID: <jc2BiCU5QJiEcIb4NT21L4HSUsZosFu-LZuK0zJMWuU=.ecb50bc6-119b-4a8c-8077-5d13b7c3a6da@github.com>

On Thu, 14 Mar 2024 11:53:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Clarify JMXConnector equivalence comment.
>  - RMIConnectionImpl needs to explicity inherit the unchecked UOE.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1936454653

From kevinw at openjdk.org  Thu Mar 14 12:23:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 12:23:09 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v12]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <XjIsXv08qda6XXHXwt6erFb5le4RzEw2MAyoDxRBZPs=.f5117016-d624-4d77-b7af-b850a36940c8@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/418b635c..91ec015f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=10-11

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

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

From kevinw at openjdk.org  Thu Mar 14 12:26:52 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 12:26:52 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v5]
In-Reply-To: <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
 <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
 <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
Message-ID: <up4t-n3yiXgwCDp2eDz3f37NGMrvGjX9J_xHqHxm6tQ=.e70dc186-6a97-48c3-bf13-dc303da5cac0@github.com>

On Mon, 11 Mar 2024 15:19:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.
>> 
>> No, nothing uses SubjectDelegationPermission.  That can be deprecated.
>> 
>>> Are there remaining tests that test the JMX fine grained permissions feature w/o depending on subject delegation?
>> 
>> Yes there are some tests other than those changed here, which use MBeanPermission in policies and become irrelevant post-SM.
>
>> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.
> 
> No issue with deprecation. I guess it can be removed once `java.security.Policy` is removed?

Thanks @dfuch for the comments and review. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1997329701

From kevinw at openjdk.org  Thu Mar 14 15:05:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 15:05:38 GMT
Subject: jmx-dev RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <_8EtVlFUCXxbPf7iLZLPpIbKPbnWVAPwzaSXVwp1j9w=.dff59ce4-146e-4ed0-88bb-068df59a1864@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

Here we are again.

I see in a good run it would print "known=50; lost=100" if we made it.  So in the failing test runs it has only had time to lose e.g. 89 or 99 notifications.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18297#pullrequestreview-1936981847

From never at openjdk.org  Thu Mar 14 16:13:46 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 14 Mar 2024 16:13:46 GMT
Subject: jmx-dev RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <a9MtJXTX7mpm4Out6bdkZ9nFfwzyZQBlbNfMhKS_xvE=.cfc30599-1998-4359-bd61-6e4b2780d2dc@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18297#pullrequestreview-1937156027

From dnsimon at openjdk.org  Thu Mar 14 16:13:47 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Mar 2024 16:13:47 GMT
Subject: jmx-dev Integrated: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <F9Chvx-3z_iY5znq-RSqF6lz6efSjL6GJ_FV9PxUuTs=.f981f107-1e77-4e49-b1f5-94712d0a56bf@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

This pull request has now been integrated.

Changeset: e6a8fdd8
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6a8fdd82c2b97f7ae74dfe8fbd3402718c9161c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8328135: javax/management/remote/mandatory/loading/MissingClassTest.java fails on libgraal

Reviewed-by: kevinw, never

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

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

From dnsimon at openjdk.org  Thu Mar 14 16:13:46 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Mar 2024 16:13:46 GMT
Subject: jmx-dev RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <6j0Sq5ayq2JIwnx1BfsHtkdUFgu8aihT7Ls_i9rUKEg=.fe203bd7-5017-44af-b06e-0ce72b2fb897@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18297#issuecomment-1997817640

From mchung at openjdk.org  Thu Mar 14 17:03:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Mar 2024 17:03:46 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v12]
In-Reply-To: <XjIsXv08qda6XXHXwt6erFb5le4RzEw2MAyoDxRBZPs=.f5117016-d624-4d77-b7af-b850a36940c8@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <XjIsXv08qda6XXHXwt6erFb5le4RzEw2MAyoDxRBZPs=.f5117016-d624-4d77-b7af-b850a36940c8@github.com>
Message-ID: <95VHtQC39WhLTqa1yWfTs4r3DglLJ7uKZPYpFag8dW4=.f2645183-9134-4d57-93bf-a39ab29ab748@github.com>

On Thu, 14 Mar 2024 12:23:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.

The spec updates are good with me.   Caught one formatting nit in the `RMIConnection` class spec.

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

> 83:  *
> 84:  * <p>JMX Subject Delegation has been removed. All methods that take a
> 85:  * delegationSubject parameter will throw UnsupportedOperationException if

Suggestion:

 * delegation subject parameter will throw {@code UnsupportedOperationException} if

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1937202285
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1525173122

From weijun at openjdk.org  Thu Mar 14 18:10:42 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 18:10:42 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv6=5D?=
In-Reply-To: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
 <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
Message-ID: <sgHC9jvz_mQFWtYkX2rREXbGel4XBTzme7hu_4hxOIY=.d04a7e2c-286f-4c14-b9b7-aa5072a1cf37@github.com>

On Wed, 13 Mar 2024 19:53:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes to MBeanServerFileAccessController.java
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:
> 
>> 27:  * @enablePreview
>> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
>> 29:  *      Need @enablePreview to use StructuredTaskScope.
> 
> jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

Yes, I noticed that. Thanks.

> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:
> 
>> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
>> 54: 
>> 55:         // Observable in the same thread in ACC mode, but not in the SV mode
> 
> Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308150
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308836

From kevinw at openjdk.org  Thu Mar 14 21:39:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 21:39:54 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v13]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <tUNI_9kbpUdXRPsYeX60m6-SMf6i1I5saxgMjEW3Ti4=.6a6b6cf6-8a14-4e0e-bfec-4e37bfb3bdff@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Missing code doc nit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/91ec015f..64c9c64a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=11-12

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

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

From kevinw at openjdk.org  Thu Mar 14 21:44:52 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 21:44:52 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v14]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <Yj8OKQh6B2Eb8W1MI_-WwLjV16qzVog87CR5DLOiNzk=.73e3b8e1-3560-4e6b-800a-13d52da4b086@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Missing code doc nit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/64c9c64a..43b10a12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=12-13

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

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

From dfuchs at openjdk.org  Fri Mar 15 09:46:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 15 Mar 2024 09:46:40 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v14]
In-Reply-To: <Yj8OKQh6B2Eb8W1MI_-WwLjV16qzVog87CR5DLOiNzk=.73e3b8e1-3560-4e6b-800a-13d52da4b086@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <Yj8OKQh6B2Eb8W1MI_-WwLjV16qzVog87CR5DLOiNzk=.73e3b8e1-3560-4e6b-800a-13d52da4b086@github.com>
Message-ID: <F7v4nCZI1wfg4kf99QgUUnHBqnkbgyCcWUqnIZpT4eo=.99a84303-e4e4-44d8-8e0b-115cb22ee7e1@github.com>

On Thu, 14 Mar 2024 21:44:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing code doc nit.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1938513465

From bhuang at openjdk.org  Mon Mar 18 16:52:47 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 18 Mar 2024 16:52:47 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests
Message-ID: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>

This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.

Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
- Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
- Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

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

Commit messages:
 - Clean up temporary files after tests complete.

Changes: https://git.openjdk.org/jdk/pull/18352/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327474
  Stats: 42 lines in 11 files changed: 20 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From alanb at openjdk.org  Mon Mar 18 22:52:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Mar 2024 22:52:21 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <W4H6LMjZxokSSq71NxDkNNbQgPxQKAJ9unepFW6K2sU=.de53b1b9-60b7-4786-925c-9accf7681f7e@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

test/jdk/java/nio/channels/unixdomain/Bind.java line 191:

> 189:             server.bind(null);
> 190:             UnixDomainSocketAddress usa = (UnixDomainSocketAddress)server.getLocalAddress();
> 191:             usa.getPath().toFile().deleteOnExit();

The test already deletes the file, I think you just want a try-finally here, same comment on a few other tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1529408542

From kevinw at openjdk.org  Tue Mar 19 17:55:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 19 Mar 2024 17:55:28 GMT
Subject: jmx-dev RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
Message-ID: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>

Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.

If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.

Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.

Increasing the timeout and tidying up the handling so we can see the specific reason in future.

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

Commit messages:
 - 8327505: Test com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails

Changes: https://git.openjdk.org/jdk/pull/18381/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18381&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327505
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18381.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18381/head:pull/18381

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

From bhuang at openjdk.org  Tue Mar 19 17:58:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 19 Mar 2024 17:58:46 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v2]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/8472c31f..620f9259

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

  Stats: 136 lines in 5 files changed: 36 ins; 13 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From weijun at openjdk.org  Wed Mar 20 01:57:51 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 01:57:51 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv7=5D?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <2WzsZtBsmeZkMUZKZS_4IGdfxGH19xrE88_uzSgRVLg=.1229163e-adb6-418e-be61-7eab69e1ed32@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - years and comments
 - Merge branch 'master' into 8296244
 - revert changes to MBeanServerFileAccessController.java
 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bb164794...dfa22af0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/80810b54..dfa22af0

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

  Stats: 384142 lines in 1493 files changed: 18191 ins; 81433 del; 284518 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From egahlin at openjdk.org  Wed Mar 20 10:27:22 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 20 Mar 2024 10:27:22 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <E9ekmv_5nb6r5rq1GBtSGAtKe8odMuOy153p42a3kzQ=.20d60bba-892c-4566-8323-8a25e10891d8@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

Speaking for JFR, we should probably just create a normal file, possibly with a filename to indicate subtest and iteration. That said, test changes for JFR looks fine, and fixing the filename is outside the scope of this bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2009218768

From weijun at openjdk.org  Wed Mar 20 14:45:50 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 14:45:50 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv8=5D?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more allow and years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/dfa22af0..1e6a7982

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

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

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

From weijun at openjdk.org  Wed Mar 20 15:02:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 15:02:25 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv8=5D?=
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <Lj2dIOon8EcxXTrhY7aevB-F-M6xQvnHHjezGoRkfBU=.c403d499-21ea-4256-a3bd-21f2d3f296f4@github.com>

On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

There is no source code change to `java.management` anymore inside this PR. They will be resolved with new bugs at [JDK-8327618](https://bugs.openjdk.org/browse/JDK-8327618) and [JDK-8328263](https://bugs.openjdk.org/browse/JDK-8328263). There are test changes in these areas in this PR to force them running with SM allowed. Ideally, these changes can be reverted when the 2 new bugs are resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/17472#issuecomment-2009779837

From mullan at openjdk.org  Wed Mar 20 20:45:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 20 Mar 2024 20:45:21 GMT
Subject: jmx-dev 
 =?utf-8?q?RFR=3A_8296244=3A_Alternate_implementation_of_?=
 =?utf-8?q?user-based_authorization_Subject_APIs_that_doesn=E2=80=99t_depe?=
 =?utf-8?q?nd_on_Security_Manager_APIs_=5Bv8=5D?=
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <6q9lWdNP10bPYE7_UAGZmKwOGgA4UqHwcZmh4jTsjRI=.7ebc2d0d-a7c3-4f89-948e-bdacaec5f355@github.com>

On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17472#pullrequestreview-1950109209

From weijun at openjdk.org  Wed Mar 20 21:28:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 21:28:29 GMT
Subject: jmx-dev =?utf-8?q?Integrated=3A_8296244=3A_Alternate_implementat?=
 =?utf-8?q?ion_of_user-based_authorization_Subject_APIs_that_doesn?=
 =?utf-8?q?=E2=80=99t_depend_on_Security_Manager_APIs?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <sVQNg8PJbPuUovgGQYsvAzGqhH0l7cSKf6bJcrEuN60=.67048ca0-828e-49ce-9deb-d06b727ecc60@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

This pull request has now been integrated.

Changeset: d32746ef
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d32746ef4a0ce6fec558274244321991be141698
Stats:     622 lines in 17 files changed: 477 ins; 27 del; 118 mod

8296244: Alternate implementation of user-based authorization Subject APIs that doesn?t depend on Security Manager APIs

Reviewed-by: mullan

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

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

From lmesnik at openjdk.org  Wed Mar 20 22:59:21 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Mar 2024 22:59:21 GMT
Subject: jmx-dev RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <dOH0NARVgPyIvPeQ-TQLjnji-M8k8kuXRCsUAh3YhcU=.a282dab7-922b-476f-842b-de9538a0795d@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18381#pullrequestreview-1950389559

From kevinw at openjdk.org  Thu Mar 21 10:39:21 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 21 Mar 2024 10:39:21 GMT
Subject: jmx-dev RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <0TmxqjJxPO4Ez8v_0tMG_CEgU6mbncMWsQDH6uspGRc=.a5f62d91-1219-4433-bc9e-8c84957e3db4@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Thanks Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/18381#issuecomment-2011885747

From jpai at openjdk.org  Thu Mar 21 14:44:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 14:44:20 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:

> 55: 
> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
> 57:             flagsFile.deleteOnExit();

Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:


File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();

and don't need any explicit deletions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534054951

From jpai at openjdk.org  Thu Mar 21 15:05:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:05:26 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <-LZotlcsvx3EbHNNn0DO-u7HsWB302dYqZ33vFTf0UA=.9728ca78-a90f-4705-8b81-de5c61d342ca@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/java/nio/channels/unixdomain/Bind.java line 201:

> 199:                 System.out.println("Null server address: " + server.getLocalAddress());
> 200:             } finally {
> 201:                 Files.deleteIfExists(usa.getPath());

`usa` can be `null` here, if it never got assigned due to some exception in the prior lines, which can lead to a `NullPointerException` here.

test/jdk/java/nio/channels/unixdomain/Bind.java line 341:

> 339:                 assertAddress(client.getRemoteAddress(), usa, "server");
> 340:             } finally {
> 341:                 Files.deleteIfExists(usa.getPath());

Same applies here about potential NullPointerException and some other places in other files as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534092806
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534095046

From jpai at openjdk.org  Thu Mar 21 15:09:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:09:21 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:

> 93: 
> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
> 95:         Path path = Utils.createTempFile("out", ".zip");

So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534105420

From bhuang at openjdk.org  Thu Mar 21 16:54:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:54:21 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v2]
In-Reply-To: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
Message-ID: <AW72Q2T6TyFJRUkyTjV-eZJdV0KUGZ-YFQa_ZatithQ=.bfd1c59b-1823-4c87-aa5f-5473959f4278@github.com>

On Thu, 21 Mar 2024 14:41:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:
> 
>> 55: 
>> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
>> 57:             flagsFile.deleteOnExit();
> 
> Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
> Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:
> 
> 
> File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();
> 
> and don't need any explicit deletions?

Hi Jaikiran, I think both solutions work for this bug. I personally prefer to place the files in the scratch directory for the ease of debugging. 
In addition, for this specific test, I am considering using File.createTempFile("CheckOriginaFlags", null, Path.of(".").toFile) instead of Files.createTempFile for consistency purposes, as Files.createTempFile may have more restrictive access permissions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534283105

From bhuang at openjdk.org  Thu Mar 21 16:59:20 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:59:20 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v2]
In-Reply-To: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
Message-ID: <5fp1NwbiBibdMUnZA8mIj76MLVvTxdA2m_z9IM8dUEc=.28d46052-8e8d-4ede-96ac-5da5d7a568a9@github.com>

On Thu, 21 Mar 2024 15:06:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:
> 
>> 93: 
>> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
>> 95:         Path path = Utils.createTempFile("out", ".zip");
> 
> So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

Yes, you are right. We don't need explicit deletion for these files by using this util method, Utils.createTempFile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534290137

From bhuang at openjdk.org  Thu Mar 21 17:13:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 17:13:46 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v3]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Fixed potential NPE issues.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/620f9259..2517f756

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

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

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

From mullan at openjdk.org  Thu Mar 21 17:46:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 17:46:20 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <H3UoDTth09CIdHaBVX8occDp0THRZY-SI9UrWHnTN0c=.c3e8aaf5-0e94-4599-9862-5a8cdc09f3be@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

The bug should have a `noreg-self` label.

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2013158192

From kevinw at openjdk.org  Mon Mar 25 14:05:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 14:05:30 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
Message-ID: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.ee3bac85-f683-48b1-9919-cd5035f0f5c4@github.com>

Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.

e.g. 

test output:
Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
	java.net.BindException: Address already in use
	
Test checks for:
        !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
		
Oops, we have an extra space in there.  A day-one typo from JDK-7195249.

While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

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

Commit messages:
 - 8328619: sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed with BindException: Address already in use

Changes: https://git.openjdk.org/jdk/pull/18470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328619
  Stats: 15 lines in 1 file changed: 5 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18470/head:pull/18470

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

From kevinw at openjdk.org  Mon Mar 25 19:07:47 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 19:07:47 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
Message-ID: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>

Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.

e.g. 

test output:
Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
	java.net.BindException: Address already in use
	
Test checks for:
        !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
		
Oops, we have an extra space in there.  A day-one typo from JDK-7195249.

While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

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

Commit messages:
 - 8328619: sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed with BindException: Address already in use

Changes: https://git.openjdk.org/jdk/pull/18470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328619
  Stats: 15 lines in 1 file changed: 5 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18470/head:pull/18470

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

From cjplummer at openjdk.org  Mon Mar 25 19:07:47 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 25 Mar 2024 19:07:47 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
In-Reply-To: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
Message-ID: <_M8m6GWVZeI9naGSojuKbhXFOvk0gzxOHGF5tVYI_6I=.a145f19f-f332-4553-b6b5-59bb2e721704@github.com>

On Mon, 25 Mar 2024 13:15:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
> 
> e.g. 
> 
> test output:
> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
> 	java.net.BindException: Address already in use
> 	
> Test checks for:
>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
> 		
> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
> 
> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

test/jdk/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java line 144:

> 142: 
> 143:         if (doTest() != 0) {
> 144:             System.out.println("FAILURE");

Would be better to print out which test failed and include the error #.

test/jdk/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java line 159:

> 157: 
> 158:         if (doTest() == 0) {
> 159:             System.out.println("FAILURE");

Would be better to print out which test failed and include the error #.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18470#discussion_r1538097934
PR Review Comment: https://git.openjdk.org/jdk/pull/18470#discussion_r1538098137

From kevinw at openjdk.org  Mon Mar 25 22:42:21 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 22:42:21 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
In-Reply-To: <_M8m6GWVZeI9naGSojuKbhXFOvk0gzxOHGF5tVYI_6I=.a145f19f-f332-4553-b6b5-59bb2e721704@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <_M8m6GWVZeI9naGSojuKbhXFOvk0gzxOHGF5tVYI_6I=.a145f19f-f332-4553-b6b5-59bb2e721704@github.com>
Message-ID: <0t2tpMCWE_kKUGwxTi4OAyi7x9AvtUBP44fFNest0TU=.20f8993a-a784-4653-9802-c92b7000bdfa@github.com>

On Mon, 25 Mar 2024 19:00:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> test/jdk/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java line 144:
> 
>> 142: 
>> 143:         if (doTest() != 0) {
>> 144:             System.out.println("FAILURE");
> 
> Would be better to print out which test failed and include the error #.

Maybe very marginally useful. I'll add it.  8-)

It's the exit code of the JVM process, being zero or not zero, and the output already printed before the "FAILURE" note that will be the guide as to what went wrong.

If it's the port failure, you'll see the retries then the eventual FAILURE, so that will be clear.

If the JVM failed to startup, it's more the output than the exit code that we want.

I really wanted the FAILURE printed because it tests two things, and when you see this test for the first time, it may not be obvious which of the tests is the actual failure - particularly as test2 is expected to cause an error and a non-zero exit code.  So it says "1 failure", and you can stare at two things that look like failures. 8-)

Maybe very marginally useful. I'll add it.  8-)

It's the exit code of the JVM process, being zero or not zero, and the output already printed before the "FAILURE" note will be the guide as to what went wrong.  (If it's the port failure, you'll see the retries then the eventual FAILURE, so that will be clear.)

If the JVM failed to startup, it's more the text output than the exit code that we want.

I really wanted the FAILURE printed because it tests two things, and when you see this test for the first time, it may not be obvious which of the tests is the actual failure - particularly as test2 is expected to cause an error and a non-zero exit code.  So it says "1 failure", and you can stare at two things that look like failures. 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18470#discussion_r1538323593

From kevinw at openjdk.org  Mon Mar 25 22:46:47 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 22:46:47 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
Message-ID: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>

> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
> 
> e.g. 
> 
> test output:
> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
> 	java.net.BindException: Address already in use
> 	
> Test checks for:
>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
> 		
> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
> 
> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

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

  show exit code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18470/files
  - new: https://git.openjdk.org/jdk/pull/18470/files/78456dac..5047f7d4

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

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

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

From lmesnik at openjdk.org  Mon Mar 25 23:45:22 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 25 Mar 2024 23:45:22 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
Message-ID: <mgP4JS60uKW7UYQZTBywVLLQMLyo9w8ce52V4sFTXUE=.3dd8ab5e-1c17-4c77-bb6c-a005e85a19ee@github.com>

On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   show exit code

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18470#pullrequestreview-1958989271

From aturbanov at openjdk.org  Tue Mar 26 07:30:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 26 Mar 2024 07:30:23 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dnzll7uMjmAmGD_8ZaudJH1Kw90Dqq-j3TEiABaWSu4=.560e44c6-d426-4799-9fe6-fc04b338ef38@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

test/jdk/java/nio/channels/unixdomain/Bind.java line 162:

> 160:         // address with space should work
> 161:         checkNormal(() -> {
> 162:             UnixDomainSocketAddress usa =  UnixDomainSocketAddress.of("with space");

Suggestion:

            UnixDomainSocketAddress usa = UnixDomainSocketAddress.of("with space");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1538701870

From michaelm at openjdk.org  Tue Mar 26 15:56:23 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 26 Mar 2024 15:56:23 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dDrW4l3mQ8774vjN_VH6nQ94gMJSKK5xcEzMpxy_EPU=.8d557a74-6ad1-44ae-ba35-cab23db68f39@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

unixdomain NIO test changes look fine to me

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1960889711

From bhuang at openjdk.org  Tue Mar 26 18:18:39 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 26 Mar 2024 18:18:39 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v4]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/nio/channels/unixdomain/Bind.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/2517f756..0f4130a9

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

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

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

From kevinw at openjdk.org  Tue Mar 26 20:00:53 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 26 Mar 2024 20:00:53 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v15]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <mtRDhj44eF5_DQmeYTy_jrTWSoT9zZe8MtVVet8Uixk=.8eb70b9a-9a3c-42b6-a72e-f04cda25e743@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge
 - Missing code doc nit.
 - Missing code doc nit.
 - RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.
 - Clarify JMXConnector equivalence comment.
 - RMIConnectionImpl needs to explicity inherit the unchecked UOE.
 - typo
 - Javadoc update
 - Remove unnecessary constructor in private class
 - Merge remote-tracking branch 'upstream/master' into 8326666_SubjectDelegation_remove
 - ... and 14 more: https://git.openjdk.org/jdk/compare/cc1800fa...903ce55b

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

Changes: https://git.openjdk.org/jdk/pull/18025/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=14
  Stats: 2026 lines in 35 files changed: 214 ins; 1632 del; 180 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From stuefe at openjdk.org  Thu Mar 28 07:07:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 28 Mar 2024 07:07:41 GMT
Subject: jmx-dev RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <A_hTLKgozHXgDrwUFKBOX5wHZylK7w6KTRiQuTcWXTM=.f5e50a43-0728-48aa-937e-572b7b7ce5d0@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Looks good!

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18381#pullrequestreview-1965321788

From kevinw at openjdk.org  Thu Mar 28 09:09:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 09:09:35 GMT
Subject: jmx-dev RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <XIVPyz6_ewFOY2YCn1lkmSGPvcrS4PAC7fHN5bWWFhs=.4d22ade7-0856-423f-8d22-11ffc11e8b5f@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Thanks Thomas!

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

PR Comment: https://git.openjdk.org/jdk/pull/18381#issuecomment-2024715786

From kevinw at openjdk.org  Thu Mar 28 09:09:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 09:09:35 GMT
Subject: jmx-dev Integrated: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <tlkDBaY_F1z-M28di8fbTQvTDMyX2VEyl7FHtXU7nTU=.40a46e3e-5ca3-45b4-aca1-33856e013f38@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

This pull request has now been integrated.

Changeset: 2b79c22c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b79c22c43a2de0815e77c9aa71f010906be8670
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8327505: Test com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails

Reviewed-by: lmesnik, stuefe

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

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

From dfuchs at openjdk.org  Thu Mar 28 11:29:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 28 Mar 2024 11:29:33 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
Message-ID: <eRRB-cxnNuV3vaR5fxnDjSsGtWW0WyKY8YFIr7GkU8g=.276e2e50-94af-44a9-827e-dba20228c279@github.com>

On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   show exit code

Looks reasonable. I wish we had a way to get rid of this getFreePort() logic.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18470#pullrequestreview-1965847115
PR Review: https://git.openjdk.org/jdk/pull/18470#pullrequestreview-1965848443

From kevinw at openjdk.org  Thu Mar 28 11:37:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 11:37:37 GMT
Subject: jmx-dev RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
Message-ID: <h1T2uTgV9qBpThObE-9RtuZePqER0C_xGnjaa_beSIA=.4cb90de1-c55f-40cc-a31b-1ed737bb7d0f@github.com>

On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   show exit code

Thanks Daniel.
Yes, the variations of the starting-with-a-free-port problem will be nice to standardize at some point... 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18470#issuecomment-2024969513

From kevinw at openjdk.org  Thu Mar 28 11:37:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 11:37:38 GMT
Subject: jmx-dev Integrated: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
In-Reply-To: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
Message-ID: <60H69ES1wIMaliGZh1PMOWBhk02yWCNNB5LnaPWF1d8=.7e1c026b-41fe-420e-a4be-2ddfc9eeea67@github.com>

On Mon, 25 Mar 2024 13:15:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
> 
> e.g. 
> 
> test output:
> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
> 	java.net.BindException: Address already in use
> 	
> Test checks for:
>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
> 		
> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
> 
> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

This pull request has now been integrated.

Changeset: 2af0312c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2af0312c958e693b1377f4c014ae8f84cabf6b83
Stats:     19 lines in 1 file changed: 7 ins; 2 del; 10 mod

8328619: sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed with BindException: Address already in use

Reviewed-by: lmesnik, dfuchs

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

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