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.
------------- Commit messages: - deal with trailing whitespace - use LF - delete foo - turn CRLF to CR - turn CRLF to CR - Update CustomFileSystemProviderTest.java - delete extraneous whitespace - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider Changes: https://git.openjdk.org/jdk/pull/22628/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22628&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331467 Stats: 317 lines in 2 files changed: 314 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22628/head:pull/22628 PR: https://git.openjdk.org/jdk/pull/22628
