Description
PathMatchingResourcePatternResolver sorts files by name when loading via PathMatchingResourcePatternResolver#doFindPathMatchingFileResources. This behavior was probably introduced in the context of #18657?
However, when resources are loaded from a JAR file, the entries are not sorted in doFindPathMatchingJarResources. JAR files might be considered to have a stable order (in contrast to directory contents, which can vary depending on the OS/filesystem), and thus need no explicit sorting. However, in many scenarios, JAR files are produced by build processes that are platform-specific, leading to variations in the order of entries depending on where it was built.
Wouldn't it make sense to sort the JAR entries alphabetically as well?
In our case, the current implementation led to a difficult-to-debug issue:
We have a Spring Boot project consisting of multiple Gradle modules. For example:
- application
- lib-entities
The application module contains the Spring Boot application that initiates classpath scanning, while the lib-entities module contains the JPA entities. Since the entities are scanned from "lib-entities.jar", the scanner registers them in the order they appear in the JAR file, which is generated by Gradle and thus platform-specific. Hibernate respects the order of registered entities, which affects scenarios such as the generation of SQL statements involving multiple JOINs.
In our case, the SQL statements generated by Hibernate were "unstable"; the exact behavior differed between CI/CD environments and local developer machines.