FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b98)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b98, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
JFileChooser on Windows has poor performance. The situation is: I have a data set of medical images. The file structure is like this:


+main_image_dir
   + image_dir_1
   + image_dir_2
   (...)
   + image_dir_5
       + image_file_1
       + image_file_2
       (...)
       + image_file_10000


so there is a "main image dir" that has a few (1-10) "image dirs", where each one of them keeps a large number of files" (>3000).

The moment where JFileChooser is blocked for several seconds is when changing directory from top to "main image dir". Then entering each of "image dir" works smooth. Moreover when you traverse up in the directory tree and enter the very same directory again ("main image dir") there's no lag - looks like JFCh caches it somewhere.

The lag of JFileChooser is enormous in comparison to native file dialog. I've seen that the problem is marked as fixed (JFileChooser performance), but apparently not in this situation.

This behaviour occurs in ALL Java versions tested (1.5.0 u 1-8, 1.6.0 b98)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open JFileChooser dialog and try to browse the directory structure described above.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Browsing performance of native file dialog.
ACTUAL -
Entering a directory which subirectories (few) have a large (>3000) number of files generates a big lag.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Using AWT component.