On Wed, 20 Nov 2024 17:27:18 GMT, jyxzwd <d...@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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489237978
