From kevinw at openjdk.org  Tue Jan  2 15:54:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 2 Jan 2024 15:54:08 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
Message-ID: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>

Remove the MLet feature and its tests.

Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
test/jdk/javax/management/MBeanServer/PostExceptionTest.java
test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

Commit messages:
 - remote old commented-out code
 - Merge remote-tracking branch 'upstream/master' into 8318707_MLet_Remove
 - (C) updates
 - Remove MLet from additional tests
 - Further test updates
 - Addtional test updates
 - Remove PrivateMLet from ClassleakTest, retain stated purpose of test
 - Merge remote-tracking branch 'upstream/master' into 8318707_MLet_Remove
 - Test update
 - remove LibraryLoader MLet test
 - ... and 5 more: https://git.openjdk.org/jdk/compare/a5cf4210...cc6e0d28

Changes: https://git.openjdk.org/jdk/pull/16363/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16363&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318707
  Stats: 3532 lines in 39 files changed: 41 ins; 3429 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/16363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16363/head:pull/16363

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

From kevinw at openjdk.org  Tue Jan  2 15:54:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 2 Jan 2024 15:54:08 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <FDIAgcrRrmE3ZN0gssl8kzyOuFcnej2T3cgcaXZWxWQ=.b8092c13-b802-4bf3-8dd4-db95d1dc9ffe@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

Additional test updates, a few more to come...

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

PR Comment: https://git.openjdk.org/jdk/pull/16363#issuecomment-1866081811

From sspitsyn at openjdk.org  Thu Jan  4 02:00:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Jan 2024 02:00:27 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

test/jdk/javax/management/Introspector/ClassLeakTest.java line 53:

> 51: 
> 52:         MBeanServer mbs = MBeanServerFactory.createMBeanServer();
> 53:         ObjectName testName = new ObjectName("x:name=Test");

Q: I'd just like to understand why it is `x:name=Test` instead of `x:type=Test` as it was before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441189776

From sspitsyn at openjdk.org  Thu Jan  4 02:16:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Jan 2024 02:16:22 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <3faU2Mez2ng8Kjo4d5xFHmLVehM6bZNBG8uY6SsB6co=.e633d63b-08fc-4362-9adc-23750f948bbe@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

test/jdk/javax/management/remote/mandatory/connection/IdleTimeoutTest.java line 214:

> 212:                                        +"]: starting at " +
> 213:                                        elapsed + "ms");
> 214:                     final String name = ":name=Test_instance_" + i;

Q: The same question, why it is not started with the `d:type=` as it was before?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441198526

From duke at openjdk.org  Thu Jan  4 02:42:22 2024
From: duke at openjdk.org (Bernd)
Date: Thu, 4 Jan 2024 02:42:22 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <FtIYhiTB1ZPbi1YFS7RsIHNKjx9Bz25RMk4vGL2P5FA=.e35d03aa-a9ff-420b-928d-29cafde147e4@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

src/java.management/share/classes/javax/management/loading/MLet.java line 68:

> 66: import javax.management.ReflectionException;
> 67: 
> 68: import static com.sun.jmx.defaults.JmxProperties.MLET_LIB_DIR;

Do those 2 statics in JmxProperties also need to be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441216307

From kevinw at openjdk.org  Thu Jan  4 09:30:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 09:30:29 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <FtIYhiTB1ZPbi1YFS7RsIHNKjx9Bz25RMk4vGL2P5FA=.e35d03aa-a9ff-420b-928d-29cafde147e4@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <FtIYhiTB1ZPbi1YFS7RsIHNKjx9Bz25RMk4vGL2P5FA=.e35d03aa-a9ff-420b-928d-29cafde147e4@github.com>
Message-ID: <fCpcTLcHhBY7lGj01GJEiw1ea9Zz7bY3B-yS5tchg94=.61e3c194-feaf-444e-bc15-8a44aa8b8ee3@github.com>

On Thu, 4 Jan 2024 02:39:17 GMT, Bernd <duke at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 68:
> 
>> 66: import javax.management.ReflectionException;
>> 67: 
>> 68: import static com.sun.jmx.defaults.JmxProperties.MLET_LIB_DIR;
> 
> Do those 2 statics in JmxProperties also need to be removed?

Yes good question - there are a couple of other definitions, they will be removed later if not now.

I was hesitant and was thinking maybe they should be removed later.  But looking again I find no other references to these, they are not part of the documented interface, so I should update this to remove them now.


src/java.management/share/classes/com/sun/jmx/defaults/JmxProperties.java
MLET_LIB_DIR only used by MLet.java
MLET_LOGGER_NAME used in same file to define MLET_LOGGER 
MLET_LOGGER used by MLet.java and MLetParser.java

JMX_INITIAL_BUILDER defined above MLET_LIB_DIR has an incorrect name in the comment.


src/java.management/share/classes/com/sun/jmx/defaults/ServiceName.java
public static final String MLET = "type=MLet"; only used by MLet.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441521876

From kevinw at openjdk.org  Thu Jan  4 10:05:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:05:27 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>
Message-ID: <bRIUzbJe7aG1idSpsM239YAptmweGq4W7OM6ZgtT_aw=.728a3041-a29e-4535-b77f-a25d2ecade0b@github.com>

On Thu, 4 Jan 2024 01:57:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> test/jdk/javax/management/Introspector/ClassLeakTest.java line 53:
> 
>> 51: 
>> 52:         MBeanServer mbs = MBeanServerFactory.createMBeanServer();
>> 53:         ObjectName testName = new ObjectName("x:name=Test");
> 
> Q: I'd just like to understand why it is `x:name=Test` instead of `x:type=Test` as it was before.

These ObjectName patterns (domain:key=value) don't matter very much for these test mbeans.
We just need an ObjectName to pass when registering the MBean, and also to use when querying, e.g. calling getMBeanInfo.

The domain part was "x" but could be empty, but it must also define at least one key=value.
The "type=mlet" might still work (I just tested: it does 8-) ), but I wanted to remove it as it would be misleading.
So we need to add some key=value and just giving a name is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441557767

From kevinw at openjdk.org  Thu Jan  4 10:25:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:25:26 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <bRIUzbJe7aG1idSpsM239YAptmweGq4W7OM6ZgtT_aw=.728a3041-a29e-4535-b77f-a25d2ecade0b@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>
 <bRIUzbJe7aG1idSpsM239YAptmweGq4W7OM6ZgtT_aw=.728a3041-a29e-4535-b77f-a25d2ecade0b@github.com>
Message-ID: <shG_MRYCUwSwCKWqTzwtePTktHnNbI6I2WAjb4a2Bos=.2bc1b528-4940-4a56-8b26-670f4b60e356@github.com>

On Thu, 4 Jan 2024 10:02:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/Introspector/ClassLeakTest.java line 53:
>> 
>>> 51: 
>>> 52:         MBeanServer mbs = MBeanServerFactory.createMBeanServer();
>>> 53:         ObjectName testName = new ObjectName("x:name=Test");
>> 
>> Q: I'd just like to understand why it is `x:name=Test` instead of `x:type=Test` as it was before.
>
> These ObjectName patterns (domain:key=value) don't matter very much for these test mbeans.
> We just need an ObjectName to pass when registering the MBean, and also to use when querying, e.g. calling getMBeanInfo.
> 
> The domain part was "x" but could be empty, but it must also define at least one key=value.
> The "type=mlet" might still work (I just tested: it does 8-) ), but I wanted to remove it as it would be misleading.
> So we need to add some key=value and just giving a name is enough.

In ClassLeakTest.java, it was creating two MBeans, but now only creates one.
It was creating a PrivateMLet (which it registers using type=mlet) and comparing classloader with another MBean.  The second MBean is created using the m-let name as the "loader name" parameter to mbs.createMBean().  This doesn't make sense without MLets, which are classloaders.  

The test retains is stated goal of checking a reference to the MBean class is not retained after it is unloaded.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441576425

From kevinw at openjdk.org  Thu Jan  4 10:33:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:33:29 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <3faU2Mez2ng8Kjo4d5xFHmLVehM6bZNBG8uY6SsB6co=.e633d63b-08fc-4362-9adc-23750f948bbe@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <3faU2Mez2ng8Kjo4d5xFHmLVehM6bZNBG8uY6SsB6co=.e633d63b-08fc-4362-9adc-23750f948bbe@github.com>
Message-ID: <xcxSTB4E34lQiRVYz1ZeOY5LmFdcqv7yUWVhNtH6a4Q=.96cc6153-2b80-4afc-b5cd-d47688f5bf04@github.com>

On Thu, 4 Jan 2024 02:13:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> test/jdk/javax/management/remote/mandatory/connection/IdleTimeoutTest.java line 214:
> 
>> 212:                                        +"]: starting at " +
>> 213:                                        elapsed + "ms");
>> 214:                     final String name = ":name=Test_instance_" + i;
> 
> Q: The same question, why it is not started with the `d:type=` as it was before?

Yes, just an identifier, the content is not very important.
type=mlet should be removed to clarify it's not an m-let, but would not stop it from working.
I could leave this one unchanged other than removing "type=mlet".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441585077

From kevinw at openjdk.org  Thu Jan  4 10:36:43 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:36:43 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v2]
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <lix2RuvTrcsGSc_ZTB9VGebvjsEnwwEqmZY1Npwgr5c=.c8d41ea5-12a8-4a6e-926c-5c0af4cc49b1@github.com>

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

  IdleTimeoutTest ObjectName more like original

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16363/files
  - new: https://git.openjdk.org/jdk/pull/16363/files/cc6e0d28..ec9f5390

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

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

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

From kevinw at openjdk.org  Thu Jan  4 10:48:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:48:38 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

  Remove unnecessary MLET_ Properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16363/files
  - new: https://git.openjdk.org/jdk/pull/16363/files/ec9f5390..29ec31f2

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

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

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

From sspitsyn at openjdk.org  Mon Jan  8 18:52:25 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 8 Jan 2024 18:52:25 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
Message-ID: <vZzXwv2j3EYB2f0X9PxJySG34wlUU16RRvHG_Y9p-us=.03086cf0-16f5-4a9d-9b0f-b1344b7d0cc3@github.com>

On Thu, 4 Jan 2024 10:48:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary MLET_ Properties

Kevin, thank you for the answers! Looks okay to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16363#pullrequestreview-1809788070

From dfuchs at openjdk.org  Wed Jan 10 14:07:29 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 14:07:29 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
Message-ID: <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>

On Thu, 4 Jan 2024 10:48:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary MLET_ Properties

test/jdk/javax/management/Introspector/ClassLeakTest.java line 55:

> 53:         ObjectName testName = new ObjectName("x:name=Test");
> 54:         Test mbean = new Test();
> 55:         mbs.registerMBean(mbean, testName);

I suspect this test should first register an MBean which is a ClassLoader implementing PrivateClassLoader, through which the TestMBean would be loaded in order to preserve the semantics of the test.

In other words, replace the MLet with a regular MBean that extends URLClassLoader and implements PrivateClassLoader and do the same thing than the original test was doing.

test/jdk/javax/management/mxbean/MXBeanLoadingTest1.java line 85:

> 83:             MBeanServer mbs = MBeanServerFactory.createMBeanServer();
> 84:             ObjectName testName = new ObjectName("x:type=test");
> 85:             ObjectInstance mb = mbs.createMBean(Test.class.getName(), testName);

Same remark here - I think we need to first register an MBean which is a ClassLoader and implements PrivateClassLoader to replace the MLet in this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447419444
PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447428031

From kevinw at openjdk.org  Wed Jan 10 15:18:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Jan 2024 15:18:25 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
Message-ID: <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>

On Wed, 10 Jan 2024 13:55:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary MLET_ Properties
>
> test/jdk/javax/management/Introspector/ClassLeakTest.java line 55:
> 
>> 53:         ObjectName testName = new ObjectName("x:name=Test");
>> 54:         Test mbean = new Test();
>> 55:         mbs.registerMBean(mbean, testName);
> 
> I suspect this test should first register an MBean which is a ClassLoader implementing PrivateClassLoader, through which the TestMBean would be loaded in order to preserve the semantics of the test.
> 
> In other words, replace the MLet with a regular MBean that extends URLClassLoader and implements PrivateClassLoader and do the same thing than the original test was doing.

I didn't see great value in it, as we no longer provide an MBean which is a ClassLoader.
Having a test MBean that extends URLClassLoader, and calling its loadClass()... is basically testing URLClassLoader? 8-)
Implementing PrivateClassLoader affects ClassLoaderRepository behaviour, but that's not tested here.
If you think this has value, we can do it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447525897

From dfuchs at openjdk.org  Wed Jan 10 16:16:26 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 16:16:26 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
Message-ID: <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>

On Wed, 10 Jan 2024 15:15:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/Introspector/ClassLeakTest.java line 55:
>> 
>>> 53:         ObjectName testName = new ObjectName("x:name=Test");
>>> 54:         Test mbean = new Test();
>>> 55:         mbs.registerMBean(mbean, testName);
>> 
>> I suspect this test should first register an MBean which is a ClassLoader implementing PrivateClassLoader, through which the TestMBean would be loaded in order to preserve the semantics of the test.
>> 
>> In other words, replace the MLet with a regular MBean that extends URLClassLoader and implements PrivateClassLoader and do the same thing than the original test was doing.
>
> I didn't see great value in it, as we no longer provide an MBean which is a ClassLoader.
> Having a test MBean that extends URLClassLoader, and calling its loadClass()... is basically testing URLClassLoader? 8-)
> Implementing PrivateClassLoader affects ClassLoaderRepository behaviour, but that's not tested here.
> If you think this has value, we can do it.

My thinking is that this tests for a leak when an MBean is created using a ClassLoader which is also an MBean. MLet was such a ready-to-use ClassLoader. We no longer have MLets, but it's still possible to register an MBean that is a class loader and use that to create another MBean whose concrete class gets loaded by that ClassLoader MBean. We're testing that the Introspector doesn't create a leak in this case. And I believe the fact that the ClassLoader MBean is a PrivateClassLoader may also be of importance in the tested scenario (maybe).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447605593

From kevinw at openjdk.org  Wed Jan 10 16:53:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Jan 2024 16:53:28 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
Message-ID: <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>

On Wed, 10 Jan 2024 16:11:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I didn't see great value in it, as we no longer provide an MBean which is a ClassLoader.
>> Having a test MBean that extends URLClassLoader, and calling its loadClass()... is basically testing URLClassLoader? 8-)
>> Implementing PrivateClassLoader affects ClassLoaderRepository behaviour, but that's not tested here.
>> If you think this has value, we can do it.
>
> My thinking is that this tests for a leak when an MBean is created using a ClassLoader which is also an MBean. MLet was such a ready-to-use ClassLoader. We no longer have MLets, but it's still possible to register an MBean that is a class loader and use that to create another MBean whose concrete class gets loaded by that ClassLoader MBean. We're testing that the Introspector doesn't create a leak in this case. And I believe the fact that the ClassLoader MBean is a PrivateClassLoader may also be of importance in the tested scenario (maybe).

Checking on the original problem noted in the test, looks like it wasn't really about ClassLoaders and MLets:
JDK-4909536: Standard MBean introspector keeps reference to last class introspected
This is what the test still tests.
Do we see value in having the MBean be a ClassLoader and checking if such MBeans are held on to...? 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447655672

From dfuchs at openjdk.org  Wed Jan 10 17:09:27 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 17:09:27 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
Message-ID: <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>

On Wed, 10 Jan 2024 16:50:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> My thinking is that this tests for a leak when an MBean is created using a ClassLoader which is also an MBean. MLet was such a ready-to-use ClassLoader. We no longer have MLets, but it's still possible to register an MBean that is a class loader and use that to create another MBean whose concrete class gets loaded by that ClassLoader MBean. We're testing that the Introspector doesn't create a leak in this case. And I believe the fact that the ClassLoader MBean is a PrivateClassLoader may also be of importance in the tested scenario (maybe).
>
> Checking on the original problem noted in the test, looks like it wasn't really about ClassLoaders and MLets:
> JDK-4909536: Standard MBean introspector keeps reference to last class introspected
> This is what the test still tests.
> Do we see value in having the MBean be a ClassLoader and checking if such MBeans are held on to...? 8-)

Yes, that's the whole point of the test. Without using an MBean which is a ClassLoader the fix cannot be tested.
1. you need to create an MBean which is an URLClassLoader, and it needs to be a PrivateClassLoader so that it's not added to the ClassLoaderRepository - let's call it  LoaderMBean.
2. you need to use that LoaderMBean to load another MBean - let's call it TestMBean. The concrete class of TestMBean needs to be loaded by the LoaderMBean - that is - LoaderMBean needs to be the defining ClassLoader for that class (the TestMBean class must not be loaded by the System/Application ClassLoader).
3. In the MBeanServer you then end up with two MBeans, one is the LoaderMBean, the other is the TestMBean whose class has been loaded by the LoaderMBean.
4. you then keep a weak reference on the _LoaderMBean_, and unregister both MBeans.
5. at that point - if the Introspector still has a strong reference to the class of the TestMBean, then the _LoaderMBean WeakReference_ will never be enqueued, because the class of the TestMBean will have a strong reference to its ClassLoader, which is _LoaderMBean_.

So you can only test that if you have an MBean which is loaded by a custom ClassLoader, because you want to verify that the Introspector doesn't hold on that ClassLoader (through the TestMBean class).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447675022

From kevinw at openjdk.org  Thu Jan 11 11:34:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 11:34:24 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
 <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
Message-ID: <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>

On Wed, 10 Jan 2024 17:06:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Checking on the original problem noted in the test, looks like it wasn't really about ClassLoaders and MLets:
>> JDK-4909536: Standard MBean introspector keeps reference to last class introspected
>> This is what the test still tests.
>> Do we see value in having the MBean be a ClassLoader and checking if such MBeans are held on to...? 8-)
>
> Yes, that's the whole point of the test. Without using an MBean which is a ClassLoader the fix cannot be tested.
> 1. you need to create an MBean which is an URLClassLoader, and it needs to be a PrivateClassLoader so that it's not added to the ClassLoaderRepository - let's call it  LoaderMBean.
> 2. you need to use that LoaderMBean to load another MBean - let's call it TestMBean. The concrete class of TestMBean needs to be loaded by the LoaderMBean - that is - LoaderMBean needs to be the defining ClassLoader for that class (the TestMBean class must not be loaded by the System/Application ClassLoader).
> 3. In the MBeanServer you then end up with two MBeans, one is the LoaderMBean, the other is the TestMBean whose class has been loaded by the LoaderMBean.
> 4. you then keep a weak reference on the _LoaderMBean_, and unregister both MBeans.
> 5. at that point - if the Introspector still has a strong reference to the class of the TestMBean, then the _LoaderMBean WeakReference_ will never be enqueued, because the class of the TestMBean will have a strong reference to its ClassLoader, which is _LoaderMBean_.
> 
> So you can only test that if you have an MBean which is loaded by a custom ClassLoader, because you want to verify that the Introspector doesn't hold on that ClassLoader (through the TestMBean class).

Hi Daniel -
I am missing see how being a ClassLoader relates to the leak where the Introspector holds on to a reference to the most recent MBean.  I didn't locate the jdk5 change, I only read a short synopsis.

I can make this test create an MBean which is a ClassLoader, and the test can do its check that having the loader MBean load a class, creates a distinct class.  I can add that update here.  But it looks like an MLet test which leaked into the Introspector test. 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1448708811

From dfuchs at openjdk.org  Thu Jan 11 12:27:21 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Jan 2024 12:27:21 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
 <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
 <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>
Message-ID: <Lo8e1Mrji7teolBaOC90qlICKy-MVbdpBU5RamNa56c=.04c2ddc1-6135-4549-9be9-a59caaf84bfe@github.com>

On Thu, 11 Jan 2024 11:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yes, that's the whole point of the test. Without using an MBean which is a ClassLoader the fix cannot be tested.
>> 1. you need to create an MBean which is an URLClassLoader, and it needs to be a PrivateClassLoader so that it's not added to the ClassLoaderRepository - let's call it  LoaderMBean.
>> 2. you need to use that LoaderMBean to load another MBean - let's call it TestMBean. The concrete class of TestMBean needs to be loaded by the LoaderMBean - that is - LoaderMBean needs to be the defining ClassLoader for that class (the TestMBean class must not be loaded by the System/Application ClassLoader).
>> 3. In the MBeanServer you then end up with two MBeans, one is the LoaderMBean, the other is the TestMBean whose class has been loaded by the LoaderMBean.
>> 4. you then keep a weak reference on the _LoaderMBean_, and unregister both MBeans.
>> 5. at that point - if the Introspector still has a strong reference to the class of the TestMBean, then the _LoaderMBean WeakReference_ will never be enqueued, because the class of the TestMBean will have a strong reference to its ClassLoader, which is _LoaderMBean_.
>> 
>> So you can only test that if you have an MBean which is loaded by a custom ClassLoader, because you want to verify that the Introspector doesn't hold on that ClassLoader (through the TestMBean class).
>
> Hi Daniel -
> I am missing see how being a ClassLoader relates to the leak where the Introspector holds on to a reference to the most recent MBean.  I didn't locate the jdk5 change, I only read a short synopsis.
> 
> I can make this test create an MBean which is a ClassLoader, and the test can do its check that having the loader MBean load a class, creates a distinct class.  I can add that update here.  But it looks like an MLet test which leaked into the Introspector test. 8-)

Hi Kevin,

To verify whether the Introspector holds a reference to a *Class Object* you need that class to be loaded by a custom class loader, and verify that the custom class loader that loaded that class can be garbage collected.

If the class loader that loaded that class has not been garbage collected after you released all references to it, then it's because the class it loaded is still referenced somewhere.

The logic of the test is as follows:
You create an MBean L which is a class loader and able to load class C. L must be the defining class loader for C.
You register L in the MBeanServer.
You ask the MBeanServer to create an MBean of class C through L (this is why you must use the variant of createMBean that takes a loader name).
You keep a weak ref to L
You unregister L and the MBean of class C from the MBeanServer and make sure the test doesn't have any strong reference to them (or to class C).
Then you start GC and wait until the weak ref to L is enqueued. If that doesn't happen, it's because the Introspector still hold a reference to class C.

You cannot test that if C has been loaded by the system class loader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1448772336

From kevinw at openjdk.org  Thu Jan 11 20:59:05 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 20:59:05 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v4]
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

  Test update using URLClassLoader MBeans, more like original tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16363/files
  - new: https://git.openjdk.org/jdk/pull/16363/files/29ec31f2..70092fa4

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

  Stats: 83 lines in 2 files changed: 68 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/16363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16363/head:pull/16363

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

From kevinw at openjdk.org  Thu Jan 11 21:06:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 21:06:26 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <Lo8e1Mrji7teolBaOC90qlICKy-MVbdpBU5RamNa56c=.04c2ddc1-6135-4549-9be9-a59caaf84bfe@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
 <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
 <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>
 <Lo8e1Mrji7teolBaOC90qlICKy-MVbdpBU5RamNa56c=.04c2ddc1-6135-4549-9be9-a59caaf84bfe@github.com>
Message-ID: <PJjTJq-s7xffC1OdFTFAXvYP31YWdXTeFlH3EKvscV0=.89d20833-e7a8-496a-85cf-5697d39a27c2@github.com>

On Thu, 11 Jan 2024 12:23:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi Daniel -
>> I am missing see how being a ClassLoader relates to the leak where the Introspector holds on to a reference to the most recent MBean.  I didn't locate the jdk5 change, I only read a short synopsis.
>> 
>> I can make this test create an MBean which is a ClassLoader, and the test can do its check that having the loader MBean load a class, creates a distinct class.  I can add that update here.  But it looks like an MLet test which leaked into the Introspector test. 8-)
>
> Hi Kevin,
> 
> To verify whether the Introspector holds a reference to a *Class Object* you need that class to be loaded by a custom class loader, and verify that the custom class loader that loaded that class can be garbage collected.
> 
> If the class loader that loaded that class has not been garbage collected after you released all references to it, then it's because the class it loaded is still referenced somewhere.
> 
> The logic of the test is as follows:
> You create an MBean L which is a class loader and able to load class C. L must be the defining class loader for C.
> You register L in the MBeanServer.
> You ask the MBeanServer to create an MBean of class C through L (this is why you must use the variant of createMBean that takes a loader name).
> You keep a weak ref to L
> You unregister L and the MBean of class C from the MBeanServer and make sure the test doesn't have any strong reference to them (or to class C).
> Then you start GC and wait until the weak ref to L is enqueued. If that doesn't happen, it's because the Introspector still hold a reference to class C.
> 
> You cannot test that if C has been loaded by the system class loader.

I am updating those two tests.
I read the test as checking that an Object instance is collected, rather than Class Object, so was favouring making it simpler.
But we can use an MBean which is a URLClassLoader, and things will be more similar to the originals.

Some of MXBeanLoadingTest1 is duplicating some of ClassLeakTest, so something for future auditing perhaps...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1449391121

From kevinw at openjdk.org  Thu Jan 11 21:06:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 21:06:29 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v3]
In-Reply-To: <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
Message-ID: <oF04jian4Rx1FKNIUBq2q5ybWbl5_HcjGv4dy134K_U=.69ca8040-28d2-47eb-a488-ea681f33605f@github.com>

On Wed, 10 Jan 2024 14:02:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary MLET_ Properties
>
> test/jdk/javax/management/mxbean/MXBeanLoadingTest1.java line 85:
> 
>> 83:             MBeanServer mbs = MBeanServerFactory.createMBeanServer();
>> 84:             ObjectName testName = new ObjectName("x:type=test");
>> 85:             ObjectInstance mb = mbs.createMBean(Test.class.getName(), testName);
> 
> Same remark here - I think we need to first register an MBean which is a ClassLoader and implements PrivateClassLoader to replace the MLet in this test.

Updated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1449391712

From dfuchs at openjdk.org  Fri Jan 12 13:47:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 12 Jan 2024 13:47:24 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v4]
In-Reply-To: <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
Message-ID: <WUf6_V4zrjG6EXlJFuaf80a2D_ZLhoD7vg2vZiUr1O0=.94ed694f-a8a3-40db-90f5-753495d1da5d@github.com>

On Thu, 11 Jan 2024 20:59:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update using URLClassLoader MBeans, more like original tests

That looks better. I would have kept the LoaderMBean and the TestMBean separate  - as using the same class for both makes the test harder to understand (it's not obvious that there are two separate copies of the TestMBean class, one loaded by the System ClassLoader, one loaded by the TestMBean itself when acting as a loader), but otherwise looks good.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16363#pullrequestreview-1818296233

From kevinw at openjdk.org  Mon Jan 15 11:12:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 15 Jan 2024 11:12:25 GMT
Subject: jmx-dev RFR: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature [v4]
In-Reply-To: <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
Message-ID: <26_kHVq8XDJUfy6Db0Z8isGhPUg-AQ6WKQDWN-ZfXeI=.744e7c4f-608b-499d-a10e-dd9bb3c28608@github.com>

On Thu, 11 Jan 2024 20:59:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update using URLClassLoader MBeans, more like original tests

Thanks Daniel and Serguei for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/16363#issuecomment-1891937743

From kevinw at openjdk.org  Mon Jan 15 11:15:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 15 Jan 2024 11:15:30 GMT
Subject: jmx-dev Integrated: 8318707: Remove the Java Management Extension
 (JMX) Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <Kkd898VNDA-CFmWbv6zWq_ZCSeeZvA6_-aIRWK-INHk=.dc3cf273-2322-4a29-ae26-9f119c382946@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

This pull request has now been integrated.

Changeset: 8c238edd
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c238eddce67219c3ad4b8fbe61bbcef17b939ab
Stats:     3543 lines in 41 files changed: 53 ins; 3404 del; 86 mod

8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature

Reviewed-by: sspitsyn, dfuchs

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

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

From mbaesken at openjdk.org  Thu Jan 25 12:35:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 12:35:54 GMT
Subject: jmx-dev RFR: JDK-8324637: get_total_or_available_swap_space_size no
 support on AIX
Message-ID: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>

The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

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

Commit messages:
 - JDK-8324637

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

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

From kevinw at openjdk.org  Thu Jan 25 14:14:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 25 Jan 2024 14:14:34 GMT
Subject: jmx-dev RFR: JDK-8324637: [aix] Implement support for reporting
 swap space in jdk.management
In-Reply-To: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
Message-ID: <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>

On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
> The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

I can't try this and don't use AIX, but it looks good.
It follows the same pattern as the other AIX cases in the file.

Although the others (e.g. line 200) don't throw_internal_error if the call returns -1, they just return -1.  You might want to do that for consistency of behaviour.

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17569#pullrequestreview-1843836792

From stuefe at openjdk.org  Thu Jan 25 14:30:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Jan 2024 14:30:41 GMT
Subject: jmx-dev RFR: JDK-8324637: [aix] Implement support for reporting
 swap space in jdk.management
In-Reply-To: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
Message-ID: <YhSlv2llqcd7jh2Ms8T-DXoH9CmGRVSPR3hwMFzteXk=.1ef43d63-120f-444e-98be-0066bf7f059a@github.com>

On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
> The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

Small nit, otherwise good.

src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c line 113:

> 111:         throw_internal_error(env, "perfstat_memory_total failed");
> 112:     }
> 113:     return available ? (jlong)(memory_info.pgsp_free * 4L * 1024L) : (jlong)(memory_info.pgsp_total * 4L * 1024L);

Do we need the cast? perfstat_memory_total_t members are all 64-bit, no?

Also, can we shorten this to:


return (available ? memory_info.pgsp_free : memory_info.pgsp_total) * 4096;

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17569#pullrequestreview-1843868729
PR Review Comment: https://git.openjdk.org/jdk/pull/17569#discussion_r1466454083

From mbaesken at openjdk.org  Thu Jan 25 15:37:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 15:37:37 GMT
Subject: jmx-dev RFR: JDK-8324637: [aix] Implement support for reporting
 swap space in jdk.management
In-Reply-To: <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
 <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>
Message-ID: <I0cINnqzSXNCDBGg4W6ckyMtfTB8_uKbszyMx4Wp5Ik=.5273575f-6dff-4751-88d1-00dea96ccb6f@github.com>

On Thu, 25 Jan 2024 14:11:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I can't try this and don't use AIX, but it looks good. It follows the same pattern as the other AIX cases in the file.
> 
> Although the others (e.g. line 200) don't throw_internal_error if the call returns -1, they just return -1. You might want to do that for consistency of behaviour.

Hi I wanted to be consistent to the other OS in get_total_or_available_swap_space_size, that#s why the throw_internal_error .

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

PR Comment: https://git.openjdk.org/jdk/pull/17569#issuecomment-1910449037

From mbaesken at openjdk.org  Thu Jan 25 15:37:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 15:37:40 GMT
Subject: jmx-dev RFR: JDK-8324637: [aix] Implement support for reporting
 swap space in jdk.management
In-Reply-To: <YhSlv2llqcd7jh2Ms8T-DXoH9CmGRVSPR3hwMFzteXk=.1ef43d63-120f-444e-98be-0066bf7f059a@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
 <YhSlv2llqcd7jh2Ms8T-DXoH9CmGRVSPR3hwMFzteXk=.1ef43d63-120f-444e-98be-0066bf7f059a@github.com>
Message-ID: <1SPU_UdKBskpy-0lp-2EASO2XEWaC0I6v7gyp-_R5dY=.cd8f28ad-924c-4c56-b338-6cd8605f5840@github.com>

On Thu, 25 Jan 2024 14:25:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Do we need the cast? perfstat_memory_total_t members are all 64-bit, no?
> 
> Also, can we shorten this to:
> 
> ```
> return (available ? memory_info.pgsp_free : memory_info.pgsp_total) * 4096;
> ```

Hi Thomas, I see no types defined here https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface but most likely you are correct and they are 64bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17569#discussion_r1466552393

From kevinw at openjdk.org  Thu Jan 25 16:46:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 25 Jan 2024 16:46:37 GMT
Subject: jmx-dev RFR: JDK-8324637: [aix] Implement support for reporting
 swap space in jdk.management
In-Reply-To: <I0cINnqzSXNCDBGg4W6ckyMtfTB8_uKbszyMx4Wp5Ik=.5273575f-6dff-4751-88d1-00dea96ccb6f@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
 <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>
 <I0cINnqzSXNCDBGg4W6ckyMtfTB8_uKbszyMx4Wp5Ik=.5273575f-6dff-4751-88d1-00dea96ccb6f@github.com>
Message-ID: <OjltmvkjGR_pFE9EuwKIvi4caQipiGVaMOh_Xr2U4mg=.bb55983e-97f0-46f5-a633-8bebb59885a4@github.com>

On Thu, 25 Jan 2024 15:33:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I can't try this and don't use AIX, but it looks good. It follows the same pattern as the other AIX cases in the file.
> > Although the others (e.g. line 200) don't throw_internal_error if the call returns -1, they just return -1. You might want to do that for consistency of behaviour.
> 
> Hi I wanted to be consistent to the other OS in get_total_or_available_swap_space_size, that#s why the throw_internal_error .

Ok yes, you can choose who to be consistent with... 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/17569#issuecomment-1910585693

From mbaesken at openjdk.org  Fri Jan 26 08:00:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Jan 2024 08:00:41 GMT
Subject: jmx-dev Integrated: JDK-8324637: [aix] Implement support for
 reporting swap space in jdk.management
In-Reply-To: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
Message-ID: <0V59YZgayJ1aqueveVFJm2WnX07bhOio4CUoAzvx19s=.19e3733c-d43f-4dea-a33a-763209269d38@github.com>

On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
> The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

This pull request has now been integrated.

Changeset: 33324a59
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33324a59ccdb220250cb74e15ce13af0e99dcb07
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8324637: [aix] Implement support for reporting swap space in jdk.management

Reviewed-by: kevinw, stuefe

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

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

From weijun at openjdk.org  Sat Jan 27 02:15:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 27 Jan 2024 02:15: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?=
Message-ID: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@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.

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

Commit messages:
 - remove exe bits
 - remove x bit
 - the patch

Changes: https://git.openjdk.org/jdk/pull/17472/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296244
  Stats: 620 lines in 14 files changed: 464 ins; 52 del; 104 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 alanb at openjdk.org  Sat Jan 27 02:15:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Jan 2024 02:15: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?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <UljMASUOYPJsDz_kxVJ6lnfnGsH3PS-p6jaV66nYYm0=.770a0e3a-a471-4779-9928-5365d955c529@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.

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

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

"is allowed or disallowed" but the detail presents them in the reverse order. I think it would be easier to read if the allowed case went first, this goes for all the methods. I understand that disallow is the default but I think a bit easier to present in that order.

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

> 296:      * {@code AccessControlContext}. When a security manager is
> 297:      * <a href=#sm-not-allowed>not allowed</a>, this method is not supported
> 298:      * and throws an {@code UnsupportedOperationException}.

I think it might be better to say "This method is intended to be used with a security manager. It throws UOE if a security manager is not allowed".

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

> 377:      * current subject binds to the period of the execution of the current
> 378:      * thread. Otherwise, it is associated with the current
> 379:      * {@code AccessControlContext}.

What would you think of "If a security manager is allowed, this method is equivalent to calling getSubject with the current ACC. If a security manager is not allowed, this returns the Subject bound to the current Thread."

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

> 409:      * Finally, this method invokes {@code AccessController.doPrivileged},
> 410:      * passing it the provided {@code PrivilegedAction},
> 411:      * as well as the newly constructed {@code AccessControlContext}.

I think this method would be easier to present if the allowed and not-allowed cases were in separate paragraphs. The reason is that the SM allowed case has a lot more test. For the not allowed case then it would be clearer to say that the calls the value returning function with the current Thread bound to the given Subject.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467824941
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467826752
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467829318
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467831325

From kevinw at openjdk.org  Mon Jan 29 15:09:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 29 Jan 2024 15:09:54 GMT
Subject: jmx-dev RFR: 8324845: management.properties text "interface name"
 is misleading
Message-ID: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>

We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.

This change only affects comment text in a properties file.

(We don't currently mention this property in other docs, e.g. in the M&M guide.)

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

Commit messages:
 - 8324845: management.properties text "interface name" is misleading

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

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

From alanb at openjdk.org  Mon Jan 29 15:27:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Jan 2024 15:27:46 GMT
Subject: jmx-dev RFR: 8324845: management.properties text "interface
 name" is misleading
In-Reply-To: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
Message-ID: <umLA7Z-w0LoiGkLIspdjUAjiDnliDq24TeYkvp8WSMY=.2f3b3c98-565c-4594-81ea-7e8ea52cfa9d@github.com>

On Mon, 29 Jan 2024 14:45:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
> 
> This change only affects comment text in a properties file.
> 
> (We don't currently mention this property in other docs, e.g. in the M&M guide.)

src/jdk.management.agent/share/conf/management.properties line 258:

> 256: #
> 257: # com.sun.management.jmxremote.host=<host-name-or-address>
> 258: #      Specifies the address on which the JMX RMI agent will bind.

The placeholder is "host-name-or-address" so it might be clearer to say the local host name or IP address in the description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17615#discussion_r1469761254

From dfuchs at openjdk.org  Tue Jan 30 14:01:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:01:24 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?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@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.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:

> 347:     @SuppressWarnings("removal")
> 348:     private Subject getSubject() {
> 349:         return Subject.current();

Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

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

> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
> 306:                     public Subject run() {
> 307:                         return Subject.current();

Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

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

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

From dfuchs at openjdk.org  Tue Jan 30 14:21:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:32 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?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <K4rNAdIWeAQ1YRVn-4-H96Aj6nZ9JCk0vQRbwcivKo8=.3acbb46f-0d68-4904-aeac-a98a16b04e8f@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.

Changes requested by dfuchs (Reviewer).

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

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

From dfuchs at openjdk.org  Tue Jan 30 14:21:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:33 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?=
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>

On Tue, 30 Jan 2024 13:53:37 GMT, Daniel Fuchs <dfuchs 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.
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
> 
>> 347:     @SuppressWarnings("removal")
>> 348:     private Subject getSubject() {
>> 349:         return Subject.current();
> 
> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:

`RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 

So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?

It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.

Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

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

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

From weijun at openjdk.org  Tue Jan 30 16:48:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:48:53 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?=
In-Reply-To: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
Message-ID: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>

On Tue, 30 Jan 2024 14:19:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
>> 
>>> 347:     @SuppressWarnings("removal")
>>> 348:     private Subject getSubject() {
>>> 349:         return Subject.current();
>> 
>> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.
>
> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
> 
> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
> 
> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
> 
> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
> 
> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

This is complicated.

The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.

I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.

I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

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

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

From weijun at openjdk.org  Tue Jan 30 16:44:46 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:44: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?=
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>

On Tue, 30 Jan 2024 13:56:53 GMT, Daniel Fuchs <dfuchs 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.
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
> 
>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>> 306:                     public Subject run() {
>> 307:                         return Subject.current();
> 
> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

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

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

From weijun at openjdk.org  Tue Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 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_=5Bv2=5D?=
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <lvRruRgRq_fjDZkadDnMl1l2mbn6riSOew16WnNQrok=.dc8a4d37-2300-4223-aaab-ea81ae8f7223@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 two additional commits since the last revision:

 - JMX needs SM
 - Resolve Alan's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/75df9b0d..a16472fb

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

  Stats: 89 lines in 10 files changed: 36 ins; 16 del; 37 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 Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 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_=5Bv2=5D?=
In-Reply-To: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
 <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
Message-ID: <HRBW0RxGY38lLNj0o0sFguRZ8nYqLjJMVZ2jQoxZkN0=.906bccdf-5e24-4449-a142-1a40491ffd13@github.com>

On Tue, 30 Jan 2024 16:45:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
>> 
>> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
>> 
>> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
>> 
>> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
>> 
>> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.
>
> This is complicated.
> 
> The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.
> 
> I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.
> 
> I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

A new commit is push. The change in this class is reverted. I'm still investigating the other one.

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

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

From weijun at openjdk.org  Tue Jan 30 21:58:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 21:58:28 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: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@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:

  fix MBeanServerFileAccessController, more test in SM

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

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

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

  Stats: 18 lines in 2 files changed: 8 ins; 0 del; 10 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 Jan 30 22:36:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 22:36: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: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
Message-ID: <QRKZc0wq2LKmqFG9rnq3h92fu3Y-u-78gYcsAlnxm2M=.436b9a55-bb43-4026-84ab-c9c3ae35e1f9@github.com>

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

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
>> 
>>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>>> 306:                     public Subject run() {
>>> 307:                         return Subject.current();
>> 
>> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?
>
> When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

I fixed it in the latest commit. The original code change is simply wrong. `AccessController.getContext()` would return different ACCs inside and outside `doPriv`.

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

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

From kevinw at openjdk.org  Wed Jan 31 21:29:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Jan 2024 21:29:14 GMT
Subject: jmx-dev RFR: 8324845: management.properties text "interface
 name" is misleading [v2]
In-Reply-To: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
Message-ID: <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>

> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
> 
> This change only affects comment text in a properties file.
> 
> (We don't currently mention this property in other docs, e.g. in the M&M guide.)

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

  text update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17615/files
  - new: https://git.openjdk.org/jdk/pull/17615/files/d1eaf87b..58cdf0cf

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

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

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

From kevinw at openjdk.org  Wed Jan 31 21:29:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Jan 2024 21:29:14 GMT
Subject: jmx-dev RFR: 8324845: management.properties text "interface
 name" is misleading [v2]
In-Reply-To: <umLA7Z-w0LoiGkLIspdjUAjiDnliDq24TeYkvp8WSMY=.2f3b3c98-565c-4594-81ea-7e8ea52cfa9d@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
 <umLA7Z-w0LoiGkLIspdjUAjiDnliDq24TeYkvp8WSMY=.2f3b3c98-565c-4594-81ea-7e8ea52cfa9d@github.com>
Message-ID: <TZLE8XWzI3OhbNr7b-NAVJ5C--TPlZqOdag2djfcF_w=.57bd932c-1171-4eb2-ae7a-5828dc27c394@github.com>

On Mon, 29 Jan 2024 15:24:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   text update
>
> src/jdk.management.agent/share/conf/management.properties line 258:
> 
>> 256: #
>> 257: # com.sun.management.jmxremote.host=<host-name-or-address>
>> 258: #      Specifies the address on which the JMX RMI agent will bind.
> 
> The placeholder is "host-name-or-address" so it might be clearer to say the local host name or IP address in the description.

ok!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17615#discussion_r1473484519

From mchung at openjdk.org  Wed Jan 31 23:16:00 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 Jan 2024 23:16:00 GMT
Subject: jmx-dev RFR: 8324845: management.properties text "interface
 name" is misleading [v2]
In-Reply-To: <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
 <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
Message-ID: <v02sksMol1wSYEAa3IZG2FDWRXRS1HTj-DtkuK0pMv8=.06fd2b94-0c7a-4042-bf72-5d9fef26d396@github.com>

On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
>> 
>> This change only affects comment text in a properties file.
>> 
>> (We don't currently mention this property in other docs, e.g. in the M&M guide.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   text update

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17615#pullrequestreview-1855055246