JDK-8328366 : Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2024-03-18
  • Updated: 2024-11-25
  • Resolved: 2024-04-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21 JDK 22 JDK 23
21.0.5Fixed 22.0.2Fixed 23 b18Fixed
Related Reports
Relates :  
JDK-8344993 - [21u] [REDO] Backport JDK-8327501 and JDK-8328366 to JDK 21
Relates :  
JDK-8327501 - Common ForkJoinPool prevents class unloading in some cases
Relates :  
JDK-8341989 - [21u] Back out JDK-8327501 and JDK-8328366
Relates :  
JDK-8342905 - Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501 redux
Description
Christian Wimmer in JDK-8327501 writes:

The fix for JDK-8327501 has a compatibility impact that has been overlooked: Using `InnocuousForkJoinWorkerThread` means that any task that runs in the common pool can no longer use `Thread.currentThread().setContextClassLoader(...)` - that unconditionally throws a `SecurityException`.

This breaks many existing Java libraries and frameworks. One example is Quarkus. See:
https://github.com/quarkusio/quarkus/issues/39526
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/338 Date: 2024-03-07 10:07:27 +0000
09-07-2024
[jdk21u-fix-request] Approval Request from Aleksey Shipilëv Fixes the regression introduced by JDK-8327501. Applies cleanly. Tests pass.
31-05-2024
[jdk22u-fix-request] Approval Request from Aleksey Shipilëv Fixes the regression introduced by JDK-8327501. Applies cleanly. Tests pass.
27-05-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/206 Date: 2024-05-15 09:32:31 +0000
15-05-2024
Changeset: 28216aa9 Author: Viktor Klang <vklang@openjdk.org> Date: 2024-04-04 18:32:59 +0000 URL: https://git.openjdk.org/jdk/commit/28216aa971ea65938117107542152abd532a5384
04-04-2024
Created https://bugs.openjdk.org/browse/JDK-8329701 to track the thread locals
04-04-2024
Quick update, the proposed fix looks good. Awaiting review and a decision as to whether this PR should restore the clearing of ThreadLocals or not.
22-03-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18374 Date: 2024-03-19 12:16:29 +0000
20-03-2024
Sounds good. Thanks for the update [~alanb].
20-03-2024
[~jeisl] A fix is in the works, no need to revert. Main thing is that we have a good set of tests for the various cases.
20-03-2024
Can we just revert JDK-8327501 until a proper fix is available?
20-03-2024
Setting the thread CCL in a task executed in a thread pool, or in this case, the FJP common pool, doesn't usually make sense. Sometimes it is necessary to defend against this and reset the TCCL after the task completes. In any case, we need to restore long standing behavior as the set method shouldn't fail with a SecurityException.
18-03-2024