On Sat, 9 Nov 2024 18:12:34 GMT, Alan Bateman <al...@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
