1.4.2_03-b02 on Windows XP

A netbeans user encounters a problem very similar to bug 4712307 but also with folders which don't have too many files. See http://www.netbeans.org/issues/show_bug.cgi?id=42079 for information about the bug originally entered against netbeans.

It takes tens of seconds to browse directories in file chooser. Thread dump at the moment of 100% CPU utilization for the many seconds shows:

"AWT-EventQueue-1" prio=7 tid=0x03512dc8 nid=0xfd8 runnable [689e000..689fd8c]
   at sun.awt.shell.Win32ShellFolder2.getAttributes0(Native Method)
   at sun.awt.shell.Win32ShellFolder2.hasAttribute(Win32ShellFolder2.java:405)
   at sun.awt.shell.Win32ShellFolder2.isDirectory(Win32ShellFolder2.java:442)
   at sun.awt.shell.Win32ShellFolderManager2.get(Win32ShellFolderManager2.java:193)
   at sun.awt.shell.ShellFolder.get(ShellFolder.java:245)
   at com.sun.java.swing.plaf.windows.WindowsFileChooserUI$DirectoryComboBoxModel.addItem(Windo

wsFileChooserUI.java:1929)
   at com.sun.java.swing.plaf.windows.WindowsFileChooserUI$DirectoryComboBoxModel.access$2800(W

indowsFileChooserUI.java:1898)
   at com.sun.java.swing.plaf.windows.WindowsFileChooserUI.doDirectoryChanged(WindowsFileChoose

rUI.java:1619)
   at com.sun.java.swing.plaf.windows.WindowsFileChooserUI.access$3100(WindowsFileChooserUI.jav

a:35)
   at com.sun.java.swing.plaf.windows.WindowsFileChooserUI$15.propertyChange(WindowsFileChooser

UI.java:1725)
   at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSuppor

t.java:264)
   at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSuppor

t.java:232)
   at javax.swing.JComponent.firePropertyChange(JComponent.java:3819)
   at javax.swing.JFileChooser.setCurrentDirectory(JFileChooser.java:541)
   at javax.swing.JFileChooser.<init>(JFileChooser.java:321)
   at javax.swing.JFileChooser.<init>(JFileChooser.java:273)
   at org.netbeans.beaninfo.editors.FileEditor.createHackedFileChooser(FileEditor.java:372)
   ...
  xxxxx@xxxxx   2004-04-19
  xxxxx@xxxxx   2004-04-20

N/A

This is reproducible using JFileChooser in NetBeans, but not with FileChooserDemo. Investigating.
  xxxxx@xxxxx   2004-04-26

This is likely a duplicate of 4480327, showing that the bug is not necessarily
network dependent.
  xxxxx@xxxxx   2004-05-24

Don't know if this is the exact same bug, but I noticed 
the issue similar to this in 1.4.2 running on XP.  It only 
seemed to be an issue when the directory I was 
viewing had several large zip files in it.  Microsoft 
added the built in zip support with WinXP and this 
seems to be causing the issue for me.  I disabled built 
in zip support and everything worked as expected.

To disable zip stuff:

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

to enable it (if you want it back)

regsvr32 %windir%\system32\zipfldr.dll

going to add another bug report for my issue just in 
case it is different.

http://forum.java.sun.com/thread.jsp?
forum=57&thread=437304&message=2342876#2342
876

Lance

From your description it does not seem to be the same bug. The behaviour described in this bug occurs all the time, even without any zip file in the directory to be viewed.

Regards,
Erik-Jan

What is really bad is that just constructing a JFileChooser is extremely slow.  You don't even need to display it.

This bug is crippling my application.  Users think it has locked up just because when I construct a JFileChooser it is taking about 10 seconds.  (and there are less than 20 files in the directory).
This is critical, but I have discovered that the delay is only that severe on some machines.  Regardless,  it should not be orders of magnitude slower than the native windows file browser like it is now.

This bug is brutal. I have finally switched to the native dialog because I can

If you have problems with JFileChooser being very slow, check out bug #6372808 (and #5050516 might be of interest).

This is still a problem in the latest java releases.  The problem is if there are .zip files in the desktop or documents folders.  JFileChooser ALWAYS scans these directories, no matter what the directory to be opened is.  The crappy workaround for me has been to remove .zip files from the desktop and docuemnts folders.  This STILL needs to be fixed.