On Sat, 14 Dec 2024 06:29:36 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 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
