PathMatchingResourcePatternResolver sorting of JAR resources

[bwaldvogel]

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:

1. application
2. 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.

[bwaldvogel]

Awesome, thanks for addressing this issue so quickly!

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

[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!