On Sat, 9 Nov 2024 08:57:17 GMT, Alan Bateman <al...@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
