FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b69)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b69, mixed mode, sharing)

A DESCRIPTION OF THE PROBLEM :
When viewing files in the JFileChooser sorting on columns is now possible by clicking on a column heading. (see bug 4752713) However clicking on the Size column results in file sizes being sorted alphabetically rather than numerically, which is not in the least bit useful.

See http://www.slac.stanford.edu/~tonyj/swing/JFileChooser.png

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open a JFileChooser, selected detailed view, sort on Size column.


REPRODUCIBILITY :
This bug can be reproduced always.
Posted Date : 2006-02-10 10:29:16.0

The code reproducing the issue, is:

JFileChooser fc = new JFileChooser(new File("C:\\"));
fc.showOpenDialog(null);
Posted Date : 2007-04-26 11:28:59.0

N/A

Cannot reproduce so far, requested environment details from the bug initiator.
Posted Date : 2006-02-17 15:56:39.0

Looks like another side of 6515169, caused by mixing up instances of java.io.File and sun.awt.shell.Win32ShellFolder2 as current directory.
Posted Date : 2007-04-26 11:30:43.0

The column sorting capability on appears to have been implemented in the Windows L&F, will it get added to the others, like the cross platform L&F? We really need this feature for my company's products, but we use the cross platform L&F...

I also encouter the problem under java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
with a jar created by J2SDK 1.4.2_12. 
I was not able to reproduce the problem on the FileChooserDemo demo that comes with java 6.0 neither on the same demo that shipped with JDK 1.4.2_12. 
On our application, the problem does not occur all the time, sometimes it happens after the second usage of the JFileChooser, in which case the Modified column disappears. I do not see anything specific we do in our code that would explain such a behaviour. The fact it occurrs to others seem to proove the problem is in the JVM. We use the Windows L & F (set at our initialization).

The bug occurs whether you compile in 1.4.2_08 or in 1.6, and it occurs in both Metal and Windows L&F so I think it is independent of L&F.  When you run in 1.6, you see the error.  The error does not show itself with FileChooserDemo.java because that program uses the default directory to open.  If you explicitly set the current directory in the chooser, then the bug shows up.

I added the following line to the FileChooserDemo just before the call to fc.showOpenDialog(...);

            fc.setCurrentDirectory(new File("C:\\windows"));

What you'll see here is worse than just a sorting problem.  When you click the button to change from wide view to tall view, you get only 3 columns: Name, Size, and Modified; but the Modified column as the file types listed in it!

When you sort by size, you see files of size 1, 1008, 10, 101, 105, 11, 2, 2074, etc.

Go up one level in the hierarchy, then come back down, and now, all 4 columns show up, and the sorting is correct.  Seems to me that when a current directory is set on a JFileChooser, somebody has to reload something to resolve this problem.

I have a screen capture, but it looks like I'm not able to post it.  Look at http://testcontent.ornith.cornell.edu/pages/brp/test/BadSort.jpg

WORK AROUND: Go up or down a level in the file system, then back to where you started, and the sorting will work.

How can this be closed when the problem was so easy to reproduce.  By closing as not reproducible, are you saying it was never reproducible or that you can't reproduce it with the current build?  In what build is it not reproducible?  Thanks.

 capt.salty.dog:
As reported in the javadesktop forums, the original reporter did not provide the test code that included the critical step of specifying the directory.  When asked for more information via email they were silent for two months so the issue was assumed to be fixed in later builds.  Of course, by December there were comments here confirming the bug in later builds.. that should have been noticed.

Regardless, it goes to show how important a test case can be in a bug report... likely far more useful that the description itself.

Thanks for taking another look.