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

[jyxzwd]

On Sat, 9 Nov 2024 18:12:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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 not 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 access JDK internal classes.

I got it.Thank you for the detailed explanation!Maybe we should consider another way to load the custom FileSystemProvider.

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

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