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

jyxzwd duke at openjdk.org
Sat Nov 9 13:09:20 UTC 2024


On Sat, 9 Nov 2024 08:57:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Use the built-in file system provider rather than the custom file system provider.
>> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.
>
> 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.

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

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


More information about the core-libs-dev mailing list