On Sat, 9 Nov 2024 13:06:30 GMT, jyxzwd <d...@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
