PathMatchingResourcePatternResolver sorts files by name when loading via PathMatchingResourcePatternResolver#doFindPathMatchingFileResources. This behavior was probably introduced in the context of https://github.com/spring-projects/spring-framework/issues/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.
Comment From: bwaldvogel
Awesome, thanks for addressing this issue so quickly!
Comment From: jhoeller
No problem, thanks for reporting it. This fits nicely with a wider revision of PathMatchingResourcePatternResolver in 6.2, including #21190 (where we cache jar entries in alphabetical order already, just did not enforce such ordering in the initial scan) as well as #33705 (where we exhaustively introspect Class-Path manifest entries now).
We will release 6.2.0-RC3 tomorrow. For the time being, this is available in the latest 6.2.0-SNAPSHOT already.
Comment From: bwaldvogel
I ran our tests with 6.2.0-SNAPSHOT and I can confirm that your change fixes our "unstable" Hibernate SQL query problem. Thanks!