RFR: 8331467: ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider

Alan Bateman alanb at openjdk.org
Sat Nov 9 18:15:12 UTC 2024


On Sat, 9 Nov 2024 13:06:30 GMT, jyxzwd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java line 51:
>> 
>>> 49:     private static final String JAVA_HOME = System.getProperty("java.home");
>>> 50:     private static final Path BOOT_MODULES_JIMAGE =
>>> 51:             sun.nio.fs.DefaultFileSystemProvider.create().getPath(JAVA_HOME, "lib", "modules");
>> 
>> This is JDK internal so if the classes in jrt-fs.jar are loaded by a custom class loader, in for example JDK 17 or 21, then this will fail.
>
> I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already included under the java.base module? This would mean that the classes in jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a custom class loader wouldn’t typically need to load them again.
> Could you kindly advise if there are any scenarios in JDK 17 or JDK 21 where custom loading of jrt-fs.jar would still be necessary?
> Thank you very much for your guidance.

The jrt file system provider supports both the current JDK and a remote/target JDK. When the JDK is not the current JDK then it loads the jrt file system provider from target's JDK jrt-fs.jar. To understand this more, try this example where you set targetJDK to the file path of another JDK on your system.


String targetJDK = .
var fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", targetJDK));
byte[] classBytes = Files.readAllBytes(fs.getPath("/modules/java.base/java/lang/String.class"));


Run with `-Xlog:class+load` and you'll see jrtfs and support jimage class files loaded from the target JDK. If you dig deeper you'll see they are loaded by a custom class loader, they are defined by the boot loader and aren't in java.base. Hopefully this makes it clear why classes in jdk.internal.jimage or jdk.internal.jrtfs can't reference JDK internal classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835482157


More information about the core-libs-dev mailing list