Java File.listFiles order: Difference between revisions

From EggeWiki
m (New page: The documentation for the Java JDK specifically mentions that the files returns can be in any order. <blockquote> There is no guarantee that the name strings in the resulting array...)
 
mNo edit summary
Line 9: Line 9:
The actual ordering of the files varies from platform to platform, and often is a result of the physical order of the files in the directory structure.  On Solaris, this order will often reverse if you copy a folder.  Generally this is not noticeable, as most tools sort the files in some order before returning them to the user.   
The actual ordering of the files varies from platform to platform, and often is a result of the physical order of the files in the directory structure.  On Solaris, this order will often reverse if you copy a folder.  Generally this is not noticeable, as most tools sort the files in some order before returning them to the user.   


Unfortunately, file ordering is important when the files are added to a classloader.  As files at the front of the classpath are searched before files at the end, if you have two different classes in your classpath, the order may not be stable.  This isn't a problem if you specify the full classpath when you launch Java, but if you load files dynamically, like [[https://jira.jboss.org/jira/browse/JBAS-5467 JBoss]] does, then your behavior is subject to change.  The following is a test case which may pass depending on your platform and file system.  For me, it fails on Windows XP, but passes on Solaris 10.  
Unfortunately, file ordering is important when the files are added to a classloader.  As files at the front of the classpath are searched before files at the end, if you have two different classes in your classpath, the order may not be stable.  This isn't a problem if you specify the full classpath when you launch Java, but if you load files dynamically, like [https://jira.jboss.org/jira/browse/JBAS-5467 JBoss] does, then your behavior is subject to change.  The following is a test case which may pass depending on your platform and file system.  For me, it fails on Windows XP, but passes on Solaris 10.  


<geshi lang="java5">
<geshi lang="java5">
Line 28: Line 28:
assert ondisk[i].getName().equals(files.get(i)) : "Expected file " + files.get(i) + " but found " + ondisk[i].getName();
assert ondisk[i].getName().equals(files.get(i)) : "Expected file " + files.get(i) + " but found " + ondisk[i].getName();
}
}
}
</geshi>
Depending on your application, you may want to sort the files alphabetically, or by last modified.  The following example emulates the '''ls -ta''' command:
<geshi lang="java5">
private static final Comparator<File> lastModified = new Comparator<File>() {
@Override
public int compare(File o1, File o2) {
return o1.lastModified() == o2.lastModified() ? 0 : (o1.lastModified() < o2.lastModified() ? 1 : -1 ) ;
}
};
public void testFileSort() throws Exception {
File[] files = new File(".").listFiles();
Arrays.sort(files, lastModified);
System.out.println(Arrays.toString(files));
}
}
</geshi>
</geshi>


[[Category:Java]]
[[Category:Java]]

Revision as of 00:28, 9 October 2009

The documentation for the Java JDK specifically mentions that the files returns can be in any order.

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.

The actual ordering of the files varies from platform to platform, and often is a result of the physical order of the files in the directory structure. On Solaris, this order will often reverse if you copy a folder. Generally this is not noticeable, as most tools sort the files in some order before returning them to the user.

Unfortunately, file ordering is important when the files are added to a classloader. As files at the front of the classpath are searched before files at the end, if you have two different classes in your classpath, the order may not be stable. This isn't a problem if you specify the full classpath when you launch Java, but if you load files dynamically, like JBoss does, then your behavior is subject to change. The following is a test case which may pass depending on your platform and file system. For me, it fails on Windows XP, but passes on Solaris 10.

<geshi lang="java5"> public static void main(String[] args) throws IOException { final List<String> files = java.util.Arrays.asList("c", "b", "a"); for (String f : files) { File file = new File(f); file.createNewFile(); file.deleteOnExit(); } FilenameFilter filenameFilter = new FilenameFilter() { public boolean accept(File dir, String name) { return files.contains(name); } }; File[] ondisk = new File(".").listFiles(filenameFilter); for(int i = 0; i < files.size(); i++) { assert ondisk[i].getName().equals(files.get(i)) : "Expected file " + files.get(i) + " but found " + ondisk[i].getName(); } } </geshi>

Depending on your application, you may want to sort the files alphabetically, or by last modified. The following example emulates the ls -ta command:

<geshi lang="java5"> private static final Comparator<File> lastModified = new Comparator<File>() { @Override public int compare(File o1, File o2) { return o1.lastModified() == o2.lastModified() ? 0 : (o1.lastModified() < o2.lastModified() ? 1 : -1 ) ; } }; public void testFileSort() throws Exception { File[] files = new File(".").listFiles(); Arrays.sort(files, lastModified); System.out.println(Arrays.toString(files)); } </geshi>