RFR: 8331467: FileSystems.getDefault fails with ClassNotFoundException if custom default provider is in run-time image [v8]

[liyazzi]

On Thu, 19 Dec 2024 09:23:27 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 pull request now contains 17 commits:
> 
>  - Enable the 'testFspInRuntimeImage' test in SetDefaultProvider
>  - Merge branch 'master' of github.com:liyazzi/jdk into 8331467
>  - revert the SetDefaultProvider
>  - 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
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/23d6f747...ebf6b1da

In addition to 'testFspInRuntimeImage', we should add more tests , right? e.g. 

1. The file system provider linked into run-time image and the application in exploded module on module path.
2. The file system provider linked into run-time image and the application in modular JAR on module path.
3. Or both of the file system provider and the application are in the same run-time image with two module.

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

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