FULL PRODUCT VERSION :
C:\dev\Software\j2sdk1.4.2_04\bin>java -version
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Mi xxxxx rosoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
My OS is XP Pro.  

A DESCRIPTION OF THE PROBLEM :
We are having issues with JFileChooser being una xxxxx  xxxxx eptably slow in windows XP.  If we sele xxxxx ted spe xxxxx ifi xxxxx  dire xxxxx tories in the  xxxxx hooser it would take up to a minute to fill the window with the files.  I was able to tra xxxxx k the issue down to only being reprodu xxxxx ible on dire xxxxx tories that have large zip files in them (5+ megs ea xxxxx h).  This immediately pointed me to the new integrated zip file features in Windows XP.  I disabled the zip support by doing:

regsvr32 /u %windir%\system32\zipfldr.dll

and the issue disappeared.  I then enabled the zip support again with:

regsvr32 %windir%\system32\zipfldr.dll

and the issue returned.

I realize this might a xxxxx tually be a Mi xxxxx rosoft bug, but it also  xxxxx ould be that Sun's native implementation is using an api that is now very slow in XP.  Perhaps just  xxxxx hanging the native method will fix the issue.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a dire xxxxx tory.
Fill it with a lot of large zip files (5+ megs ea xxxxx h)
Load JFileChooser to that new dire xxxxx tory.
Observe slowness

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the File list for the dire xxxxx tory would open at about the same speed as other dire xxxxx tories with non-zip entries.
ACTUAL -
Very slow JFileChooser painting of dire xxxxx toryM-^OÀ»s  xxxxx ontent

REPRODUCIBILITY :
This bug  xxxxx an be reprodu xxxxx ed always.
(In xxxxx ident Review ID: 270259) 
======================================================================
Posted Date : 2005-11-08 00:54:22.0

N/A

Will address for next release.
  xxxxx@xxxxx   2004-06-01
In Win32ShellFolder.isDirectory(), ATTRIB_HASSUBFOLDER is requested first of all, what enforces Windows to unzip compressed folders (that are actually ZIP files). The check for ATTRIB_HASSUBFOLDER should be removed, because it is unnecessary there. MSDN doesn't say that folders can have SFGAO_HASSUBFOLDER set and SFGAO_FOLDER unset at the same time, so check for ATTRIB_FOLDER is enough.
Posted Date : 2007-10-03 14:47:57.0

This issue has been already fixed in jdk7, but as for jdk6 update releases, it will be shipped with 6u10 only according to actual release timetable. It's quite unfortunate, but it's so.
Posted Date : 2008-03-19 12:15:05.0

I experienced this bug where the JFileChooser took an exceedingly long time just to be constructed (~5min).  Disabling the XP zip support fixed this.  I profiled it to find that 98% of the time was spent in sun.awt.shell.Win32ShellFolder2.hasAttribute(int) on only 28 invocations.

What version of java did you try? Mustang beta uses fewer calls to hasAttribute. Does it seem to make a difference?

I was hitting this bug too, and mistook it for 6372808.  I was having the problem will all versions of java, including Mustang.

This bug is probably the same as, or at least related to, bug #6372808 - check that out. Also bug #5033747 might be related. 

In the comments to bug #4480327 there was a hint to JFileChooser taking long to instantiate when having a shortcut to an offline network-share on the desktop. I obviously had the same problem - it took minutes before, now, after having deleted the shortcut, everything is fine and smooth. Might be a bug rather in Windows when in Java, but it only showed up in Java so far (although it took an accordingly long time to access the shortcut when deleting it, but in the opposite to Java I expect such behaviour by Windows *g*). If I can help by providing details, please contact me ...

I am using Windows XP, and just updated to SE 6.0.2.  The JFileChooser is opening to the {local drive} and is now taking, a minimum of 10 seconds to instantiate and display.  

Fixed in 1.7, but will it also be fixed in 1.6.0_04?

This is still broken in 1.6.0_04.  My application takes over 10 seconds to initialize a JFileChooser().  It's instantaenous in 1.6.0_01, which is the last 1.6 version that did not have this bug in it.  It's broken in _02 and _03 and _04.

This bug is fixed in 6u10 (or JDK 6 update 10), it has not been fixed in 6u4. 
 
Release Fixed:  7(b22), 6u10(b07) 

You can find 6u10, as an early access release on this site:
https://jdk6.dev.java.net/6uNea.html

-Roger
Sun Microsystems

this bug is not fixed in jdk1.6 u10 , i had to disable windows zip support to fix it

(1.6.0_06): same problem here, I dont think it has anything to do with the contructor, just navigating in JFileChooser to a directory with large zip files hangs/slows down the chooser for a long time (minutes). 

Any fix that alters the native environment is not usable for me since this is software distributed to customers.

does anyone know whether this bug also appears when the compressed folders dont have the extension .zip /.rar 

i see this bug already existed in 2004. please fix; this is a show stopper for me. are there any workarounds? I cannot disable zip on customer computers.