jmx-dev RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature [v3]

[Kevin Walls]

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