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

[Alan Bateman]

On Sat, 14 Dec 2024 06:29:36 GMT, liyazzi <duke at openjdk.org> wrote:

>> For two cases:
>> 
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the ImageReaderFactory was loaded by boot class loader,then init the `Path BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which is obtained through reflection,due to it is in jdk internal.
>> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8 compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE` field.
>> Then we can avoid the circular dependencies in class loading caused by loading the defaultSystemProvider.
>
> liyazzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8331467
>  - add test case in test/jdk/java/nio/file/spi/SetDefaultProvider.java as the test of this issue
>  - add '\s' to avoid trailing whiteSpace
>  - empty commit
>  - remove the '\s' and trailing whitespace
>  - add test.jdk value log
>  - deal with trailing whitespace
>  - use LF
>  - delete foo
>  - turn CRLF to CR
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/05eab106...c97dba99

The test change means this test ends up with two copies of the test provider. I'll create an issue in JBS to refactor this test to allow it be used for all cases (class path, module path, linked into run-time image). That would make this much simpler.

The bigger question is whether specification of FileSystems.getDefault should be revised to specify how it should work when the default file system provider is deployed as a module (which would cover the case where there the provider has been linked into the a run-time image). The reasons the tests work is because the provider module exports the package with the provider class but it should be possible to fully encapsulate it. I'll try to do some think on what the right thing to do there is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22628#issuecomment-2543683287