Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
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) ======================================================================
|