United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-5050516 JFileChooser very slow in XP if directory contains large zip files
JDK-5050516 : JFileChooser very slow in XP if directory contains large zip files

Details
Type:
Bug
Submit Date:
2004-05-20
Status:
Resolved
Updated Date:
2010-07-09
Project Name:
JDK
Resolved Date:
2007-10-10
Component:
client-libs
OS:
generic,windows_xp
Sub-Component:
javax.swing
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.5.1,1.4.2,5.0,6
Fixed Versions:

Related Reports
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

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

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-09-25
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.
                                     
2007-08-09
SUGGESTED FIX

The check for ATTRIB_HASSUBFOLDER should be removed
                                     
2007-10-03
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.
                                     
2008-03-19



Hardware and Software, Engineered to Work Together