RFR: 8331467: ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider [v2]

[jyxzwd]

On Wed, 20 Nov 2024 18:02:35 GMT, Alan Bateman <alanb at 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