The OpenJDK Quality Group promotes the testing of FOSS projects with OpenJDK Early-Access builds as a way to improve the overall quality of the release. This heads-up is part of a regular communication sent to the projects involved. To learn more about the program, and how-to join, please check here.

JDK 20 - Deprecate and Disable the Legacy Parallel Class Loading Workaround for Non-parallel-capable Class Loaders

Prior to JDK 7, custom class loaders using non-hierarchical class delegation model were prone to deadlock. A workaround was added in the HotSpot VM (JDK 6) to allow parallel class loading for non-parallel-capable class loaders to avoid deadlocks.

Parallel-capable class loaders were introduced in Java SE 7 to support parallel class loading to implement a deadlock-free class loader using a non-hierarchical class delegation model. This resources below describe how to migrate those class loaders depending on this workaround to be multi-threaded parallel-capable class loaders.

This workaround was intended to allow those developers to migrate to the new mechanism. JDK 7 was released 11 years ago so it is now expected that those deadlock-prone custom class loaders have been migrated to the parallel-capable class loaders. As a consequence, this workaround is removed in JDK 20 as it impedes eliminating the object monitors from pinning for virtual threads.

We suggest confirming that your codebase is not relying on this legacy workaround. If it still is, you should migrate away from it ASAP. Please note that the legacy behavior can be temporary re-enabled using a special flag.

More Information

• Multithreaded Custom Class Loaders in Java SE 7
• Class Loader API Modifications for Deadlock Fix
• JDK-8295673 Release Notes
• JDK-8295848 Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders

~