Fixes ClassPathURLLoader cannot find files under GraalVM Native Image

[linghengqian]

For #30139.

Changes proposed in this pull request:

• Fixes ClassPathURLLoader cannot find files under GraalVM Native Image. If we can't use java.io.InputStream in this class, then obviously we need to manually open NativeImageResourceFileSystem under GraalVM Native Image. Split this PR from the Add GraalVM Reachability Metadata and corresponding nativeTest for Seata integration #30138 side for clarification.
• Creating a java.io.File instance will break usage in both JAR(ZipFileSystemProvider) and GraalVM Native Image(NativeImageResourceFileSystemProvider). Refer to Calling java.nio.file.Path#toFile under Native Image will result in java.lang.UnsupportedOperationException oracle/graal#7804 .
• Obviously, developers cannot create java.io.File instances via URLs like resource:file:/resources/{entry} or jar:file:/resources/{entry}, because creating java.io.File instances is only supported by the File System corresponding to the URL of file:/resources/{entry}.

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.

[terrymanu]

graalvm is too special, could it be separate with normal logic and put them into a concentrated graalvm module?

[linghengqian]

graalvm is too special, could it be separate with normal logic and put them into a concentrated graalvm module?

@terrymanu

• This is essentially a problem of determining the URL, refer to processing of https://github.com/oracle/graal/blob/vm-ce-23.1.2/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/resources/NativeImageResourceFileSystemProvider.java . The corresponding File System is designed to need to be opened manually.
• There are several URLs involved here,
  • resource:file:/resources/{entry}, that is com.oracle.svm.core.jdk.resources.NativeImageResourceFileSystemProvider in the GraalVM Native Image
  • file:/resources/{entry}, that is sun.nio.fs.UnixFileSystemProvider in the IDE debugging environment
  • jar:file:/resources/{entry}, that is jdk.nio.zipfs.ZipFileSystemProvider in the JAR
• I removed the use of org.graalvm.nativeimage.imagecode, what about Protocol? Or should I continue to use InputStream to handle this problem?

[terrymanu]

graalvm is too special, could it be separate with normal logic and put them into a concentrated graalvm module?

@terrymanu

• This is essentially a problem of determining the URL, refer to processing of https://github.com/oracle/graal/blob/vm-ce-23.1.2/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/resources/NativeImageResourceFileSystemProvider.java . The corresponding File System is designed to need to be opened manually.

• There are several URLs involved here,

  • resource:file:/resources/{entry}, that is com.oracle.svm.core.jdk.resources.NativeImageResourceFileSystemProvider in the GraalVM Native Image
  • file:/resources/{entry}, that is, sun.nio.fs.UnixFileSystemProvider in the IDE debugging environment
  • jar:file:/resources/{entry}, that is jdk.nio.zipfs.ZipFileSystemProvider in the JAR

• I removed the use of org.graalvm.nativeimage.imagecode, what about Protocol? Or should I continue to use InputStream to handle this problem?

Use InputStream is a good idea

[linghengqian]

Use InputStream is a good idea

• Done.

[linghengqian]

• @terrymanu Is there anything holding back the current PR from being merged? As shardingsphere refactor further, the number of JSON entries that need to be modified to fix nativeTest increases.