On Wed, 20 Nov 2024 18:02:35 GMT, Alan Bateman <al...@openjdk.org> wrote:
> > yeah,I tested it a few mins ago.It works well in the situation mentioned in > > the issue and in the normal situation, also when a remote/target jdk is > > set. But I have a doubt, when only using the local jdk, no > > remote/targetjdk, that is, ImageReaderFactory.class.getClassLoader() will > > be null, when loading any class located in the runtime image, > > BOOT_MODULES_JIMAGE will always be the path provided by the built-in > > default FileSystemProvider. The user-defined FileSystemProvider will make > > no contribution to loading the classes that exist in the image in this > > case.Although the built-in default FileSystemProvider is sufficient, are my > > concerns redundant? > > If a tool is using jrtfs to get at the classes/resources in another run-time > image then you'll have two versions of the jrt FileSystemProvider and the > support jimage support in use. For the local case (current runtime), the > classes comes from java.base and be defined to the boot module. For the > remote case, the classes will be loaded from the remote jrt-fs.jar and > defined to custom class loader (see JrtFsLoader in JrtFileSystemProvider). > > It gets complicated once you replace the default file system provider. The > change means the "local" provider and image reader won't go through the > custom file system provider. The "remote" provider and image reader will have > their I/O intercepted by the custom file system provider. I see, thank you for your detailed explanation! Should I submit the modifications mentioned above to a commit, or should I conduct further testing first? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489269311
