On Wed, 10 Jan 2024 16:11:35 GMT, Daniel Fuchs <dfu...@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
