Use java.nio and FileSystems to resolve files in PathMatchingResourcePatternResolver

[dsyer]

The JDK has decent support for walking a file system (via FileSystem in java.nio), but Spring still uses hand-rolled pre-Java 7 code. Also, in principle, FileSystem can be an abstraction used to express any hierarchy of resources through their URIs. This is a good fit with the Spring Resource abstraction, and for instance would mean that native images could potentially do classpath scanning through a custom URI and FileSystem already provided by GraalVM (oracle/graal#1108).

Here's a prototype that shows how it could work: https://github.com/scratches/pattern-resolver-poc. It replaces one method (and several subsidiary protected methods) in PathMatchingResourcePatternResolver. The unit test is a copy from spring-core verifying that it works as normal with files. It also works with classpath resources in native images, as demonstrated by the main() method provided.

Slightly ugly is the hack that works around the fact that GraalVM's FileSystem for resource: URIs doesn't accept leading or trailing slashes in folder names (the opposite of the file: implementation provided by the JDK, but similar to the way ClassLoader.getResource() works).

[dsyer]

Update: you can run the tests in the project above in a native image (./mvnw test -PnativeTest), but 1 of them had to be modified (there is no File associated with a classpath resource) and another disabled (you can't scan from the root of the classpath)

[bclozel]

I've raised oracle/graal#5020 to address the lack of root resource resolution. I think this is a must have if we want to offer this feature in Framework. We don't need to wait for a fix in GraalVM though, as this issue would cover quite a lot of cases already.