RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3]
Alan Bateman
alanb at openjdk.org
Tue Nov 8 18:01:27 UTC 2022
On Tue, 8 Nov 2022 17:03:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> Can one create a class loader to override this function, and does one expect the JVM to synchronize it on the system class loader object (returned by getSystemClassLoader)? This feels too remote to try to explain in a CSR.
>
> I'll look to see if we have tests for this case.
In most cases, system class loader == the application class loader. It should be very rare to run with -Djava.system.class.loader=... but we know of a few application servers that do use it.
The behavior prior to JDK 9 was to always call the app class loader's appendToClassPathForInstrumentation. This changed in JDK 9 (see JDK-8160950) to call the custom system class loader's appendToClassPathForInstrumentation. The changes for JDK-8160950 added test/java/lang/instrument/CustomSystemLoader so running the test/java/lang/instrument tests would be good. I'd forgotten about that change when initially commenting here.
There isn't anything in the API docs about synchronization on the class loader object, nothing should be depending on that but it wouldn't do any harm to note the change in a release note.
-------------
PR: https://git.openjdk.org/jdk/pull/11023
More information about the core-libs-dev
mailing list