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).