Description
Say.li opened SPR-14085 and commented
java jdk (new File("").listFiles()) api:
listFiles public File[] listFiles() Returns an array of abstract pathnames denoting the files in the directory denoted by this abstract pathname. If this abstract pathname does not denote a directory, then this method returns null. Otherwise an array of File objects is returned, one for each file or directory in the directory. Pathnames denoting the directory itself and the directory's parent directory are not included in the result. Each resulting abstract pathname is constructed from this abstract pathname using the File(File, String) constructor. Therefore if this pathname is absolute then each resulting pathname is absolute; if this pathname is relative then each resulting pathname will be relative to the same directory.
There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order.
Note that the Files class defines the newDirectoryStream method to open a directory and iterate over the names of the files in the directory. This may use less resources when working with very large directories.
Returns: An array of abstract pathnames denoting the files and directories in the directory denoted by this abstract pathname. The array will be empty if the directory is empty. Returns null if this abstract pathname does not denote a directory, or if an I/O error occurs. Throws: SecurityException - If a security manager exists and its SecurityManager.checkRead(String) method denies read access to the directory Since:
Problem location： PathMatchingResourcePatternResolver(class) doRetrieveMatchingFiles(method)(line number:687)
(bug)
File[] dirContents = dir.listFiles();
Solution: add a alphabetical order.
The same code in different environmental order is not the same (can not start the project). I have encountered such a situation.
code:
public static void main(String[] args) {
File[] dirContents = new File("/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring").listFiles();
for (File f : dirContents) {
System.out.println(f.getPath());
}
}
Console:
windows:
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/applicationContext-user.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/applicationContext.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/Provider.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/Consumer.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/rabbit.xml
i linux:
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/Provider.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/Consumer.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/applicationContext-user.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/applicationContext.xml
/home/say/git/chop-usercenter/chop-usercenter-provider/src/main/resources/spring/rabbit.xml
Issue Links:
- PathMatchingResourcePatternResolver should close jar file from JarURLConnection if not cached [SPR-6295] #10961 PathMatchingResourcePatternResolver should close jar file from JarURLConnection if not cached
- PathMatchingResourcePatternResolver does not consider manifest based classpaths [SPR-13685] #18260 PathMatchingResourcePatternResolver does not consider manifest based classpaths
- PathMatchingResourcePatternResolver should enforce OS-independent sorting of directory content [SPR-16838] #21378 PathMatchingResourcePatternResolver should enforce OS-independent sorting of directory content
Referenced from: commits 55f1c98