JDK-5050516 : JFileChooser very slow in XP if directory contains large zip files
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.5.1,1.4.2,5.0,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-05-20
  • Updated: 2010-07-09
  • Resolved: 2007-10-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u10Fixed 7 b22Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Name: rmT116609			Date: 05/20/2004


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 :
Microsoft 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 unacceptably slow in windows XP.  If we selected specific directories in the chooser it would take up to a minute to fill the window with the files.  I was able to track the issue down to only being reproducible on directories that have large zip files in them (5+ megs each).  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 actually be a Microsoft bug, but it also could be that Sun's native implementation is using an api that is now very slow in XP.  Perhaps just changing the native method will fix the issue.

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

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the File list for the directory would open at about the same speed as other directories with non-zip entries.
ACTUAL -
Very slow JFileChooser painting of directoryM-^O����s content

REPRODUCIBILITY :
This bug can be reproduced always.
(Incident Review ID: 270259) 
======================================================================

Comments
EVALUATION 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.
19-03-2008

SUGGESTED FIX The check for ATTRIB_HASSUBFOLDER should be removed
03-10-2007

EVALUATION 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.
09-08-2007

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
25-09-2004

EVALUATION Will address for next release. ###@###.### 2004-06-01
01-06-2004