> This bug was discovered during the development of > [JDK-6824466](https://bugs.openjdk.java.net/browse/JDK-6824466): when CDS is > enabled, if `BootLoader::loadClassOrNull` is called before `initPhase2`, it > would trigger the initialization of the archived module graph in the wrong > order. Because of unanticipated nesting of `<clinit>` methods, > `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` > operations to fail. > > The fix has 2 parts: > > - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. > This avoids triggering the archived module graph initialization. Instead, it > makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't > actually need a `ClassLoader` instance for this call, so I changed > `Classloader::findBootstrapClassOrNull()` to be a static method. > - The object returned by `BootLoader::getServicesCatalog()` is now maintained > inside `jdk.internal.loader.ClassLoaders`. Although not strictly required > for the fix, this simplifies the initialization of the archived module graph. > It also makes the logic consistent for the 3 built-in loaders > (boot/platform/app). > > Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy > is no longer reproducible after I applied this patch on her branch.
Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: cleaned up ClassLoaders.setArchivedServicesCatalog ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3992/files - new: https://git.openjdk.java.net/jdk/pull/3992/files/8067306a..4cd981c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3992&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3992.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3992/head:pull/3992 PR: https://git.openjdk.java.net/jdk/pull/3992
