On Thu, 19 Dec 2024 09:23:27 GMT, liyazzi <d...@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
