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

[Daniel Fuchs]

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