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/4cb2085f...c97dba99

I've created [JDK-8346463](https://bugs.openjdk.org/browse/JDK-8346463) and [pull/22797](https://github.com/openjdk/jdk/pull/22797) with changes to the SetDefautProvider test to make it easier to add more scenarios. The updated tests exercises the custom default provider as both an exploded and packaged module. It includes a (disabled) test for the case that the module is linked into the run-time image. If that PR is approved then I think it gives us a better base than the existing test and avoids the changes in this PR to duplicate the test provider.

As regards FileSystems.getDefault then there a few directions to ponder. Right now, and since JDK 9, it works if the provider class is accessible to java.base. This could be specified or directions like you propose where the value of the system property can be $MODULE/$CLASS is possible too. This needs mulling over as maybe a broader audit to see if there are other places where it would work the same way. So I think we should keep it separate for now.

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

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