RFR: 8368500: ContextClassLoader cannot be reset on threads in ForkJoinPool.commonPool() [v2]
Viktor Klang
vklang at openjdk.org
Mon Oct 13 09:50:16 UTC 2025
On Tue, 7 Oct 2025 12:34:25 GMT, Johny Jose <duke at openjdk.org> wrote:
>> The permanent disabling of the Security Manager in JDK 24 allow setCCL to set the CCL to a custom class loader. However, it doesn't allow it to be set to a custom class loader and then "reset" back to the system class loader before executing further code in the task. The changes are made to relax the restriction in setCCL to reset back to system class loader
>
> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
>
> Review changes
test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 32:
> 30:
> 31: import java.util.concurrent.CountDownLatch;
> 32: import java.util.concurrent.ForkJoinPool;
Suggestion:
test/jdk/java/util/concurrent/forkjoin/ContextClassLoaderTest.java line 59:
> 57: assertSame(originalCCL, thread.getContextClassLoader(), "Original context class loader not restored");
> 58: latch.countDown();
> 59: });
These assertion failures will not get re-thrown in the test runner thread, so failures will just mean that the test hangs until the harness times it out.
If you do a commonPool().submit(…) instead and then get the Future returned by that, then you can do .get() on the Future to have it throw an exception in case of failure.
If you want to keep using `execute(…)` you can do the equivalent but instead wrapping the test logic in a try-catch and then set an exception on a pre-constructed Future.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2411082731
PR Review Comment: https://git.openjdk.org/jdk/pull/27648#discussion_r2411094836
More information about the core-libs-dev
mailing list