FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b66)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b66, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600] (with sp2)

A DESCRIPTION OF THE PROBLEM :
The JFileChooser is very slow to open (towards 10 seconds), at least the first time. Subsequent instantiations and navigation of the GUI are in some cases faster, and other cases not.

As suggested in bug 6317789, I tried setting "useShellFolder" to False, as in:
putClientProperty("FileChooser.useShellFolder", Boolean.FALSE);

This made the dialog appear "instantly", and all browsing is pretty much instant, with file sizes and all, but without the elaborate windows GUI.

Using JProfiler under the opening sequence, I found the following:
87.1% of the time used is in the JFileChooser.<init>. This is again broken down to 48.9% in .setup(), and 38.2% in .setCurrentDirectory(). These again both boil down through the following chain:
  sun.awt.shell.ShellFolder.get
  sun.awt.shell.Win32ShellFolderManager2.get
  sun.awt.shell.Win32ShellFolder2.isDirectory
  sun.awt.shell.Win32ShellFolder2.hasAttribute
  sun.awt.shell.Win32ShellFolder2.getAttributes0()
.. with 35.3.% and 34.1% respectively. Thus, ~70% of the time is spent in this one method.

This happens both on the jdk 1.5 (cutting edge), and now also on the latest snapshot of 1.6.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Check out the attached source. This might not be a fantastic way to code, but it demonstrates some weirdness I at least experience consistently on my setup.

The three booleans will controll different "bug-aspects":
  _fixChooser sets the useShellFolder to false
  _windowsLookAndFeel sets the windows look and feel (giving the "elaborate" FileChooser)
  _makeChooserInMain simply instantiates a JFileChooser in the main thread, and does nothing else with it.

If _fixChooser is true, the whole "application" is fast, both instantiations of JFileChooser and navigations of it, regardless of the other two booleans.

If _fixChooser is false, then both instantiations and navigation is very slow unless _makeChooserInMain is true. This is what I find very puzzling: if you make a JFileChooser in main before the main thread exits, then this will delay the startup by 7-8 seconds, but subsequent instantiations of the JFileChooser and all navigation is very fast.

The _windowsLookAndFeel does not affect the speed aspect at all.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Fast instantiation and GUI-navigation of the JFileChooser
ACTUAL -
Unusable slow, always in the first instantiation, and in certain circumstances for every "move" within the GUI and all subsequent instantiations.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.Container;
import java.awt.Dimension;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JButton;
import javax.swing.JFileChooser;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import javax.swing.UnsupportedLookAndFeelException;
import javax.swing.WindowConstants;

public class Test2 {

	static boolean _fixChooser = false;

	static boolean _windowsLookAndFeek = true;

	static boolean _makeChooserInMain = true;

	public static void main(String[] args) throws InterruptedException {
		System.out.println("start");
		if (_windowsLookAndFeek) {
			try {
				UIManager.setLookAndFeel(new com.sun.java.swing.plaf.windows.WindowsLookAndFeel());
			}
			catch (UnsupportedLookAndFeelException e) {
				e.printStackTrace();
			}
		}
		if (_makeChooserInMain) {
			getJFileChooser();
		}
		MyFrame myFrame = new MyFrame();
		myFrame.startUp();
		System.out.println("leaving main.");
	}

	static JFileChooser getJFileChooser() {
		long startTime = System.currentTimeMillis();
		System.out.println(Thread.currentThread() + " :: Before new JFileChooser()");
		JFileChooser ret;
		if (_fixChooser) {
			ret = new JFileChooser() {
				private static final long serialVersionUID = 1541813407103968847L;

				@Override
				public void updateUI() {
					putClientProperty("FileChooser.useShellFolder", Boolean.FALSE);
					super.updateUI();
				}
			};
		}
		else {
			ret = new JFileChooser();
		}
		System.out.println(Thread.currentThread() + " :: After new JFileChooser(), took ["
				+ (System.currentTimeMillis() - startTime) + "].");
		return ret;
	}

	public static class MyFrame extends JFrame {
		public void startUp() {
			setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
			SwingUtilities.invokeLater(new Runnable() {
				public void run() {
					build();
					setSize(new Dimension(100, 100));
					setVisible(true);
				}
			});
		}

		public void build() {
			Container contentPane = getContentPane();
			JButton launchChooser = new JButton("launch chooser");
			launchChooser.addActionListener(new ActionListener() {
				public void actionPerformed(ActionEvent e) {
					getJFileChooser().showDialog(null, "test!");
					System.out.println(".showDialog exited.");
				}
			});
			contentPane.add(launchChooser);
		}
	}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Make a JFileChooser instance in the main thread (which gives a one-time impact), or set the useShellFolder to false.
Posted Date : 2006-01-16 07:58:49.0

N/A

The method sun.awt.shell.Win32ShellFolder2.getAttributes0() should be further profiled and the bottleneck should be eliminated. Thanks to Nelson, the originator of this CR, for his excellent investigation.
Posted Date : 2006-01-23 16:41:02.0

Nelson informed me that the issue was actually investigated by Endre Stolsvik, a customer and the author of initial incident, so I would like to say: Thank you Endre!
Posted Date : 2006-10-26 14:02:21.0

It seems this bug is a duplicate of CR 5050516. I can't reproduce the bug with current build and with old builds. As I see from the description the stacktrace contains the next lines:
  sun.awt.shell.Win32ShellFolder2.isDirectory
  sun.awt.shell.Win32ShellFolder2.hasAttribute

Actually the fix of CR 5050516 fixes the problem in the isDirectory() method: one invocation of the hasAttribute() method was removed and that invocation took a lot of time on ZIP files.
Posted Date : 2009-08-24 09:44:24.0

Even stranger, if you move the instantiation of the JFileChooser in the main-thread below the instantiation and startup of the JFrame, you also get very fast response when instantiation and invoking another JFileChooser from "within" the JFrame (in the eventdispatch thread), even before the instantiation is finished in main. Thus it seems to be something with the actual instantiation of the object itself, rather than caching of its internal data.

I also tried to just instantiate several JFileChoosers within the main thread. This results in sequential slowness: each takes 7-8 seconds to make..

Here's some trimmed code:
-------------
import javax.swing.JFileChooser;

public class Test4 {
	public static void main(String[] args) throws InterruptedException {
		Thread t1 = new MyThread();
		t1.setName("T1");
		Thread t2 = new MyThread();
		t2.setName("T2");
		// --
		t1.start();
		Thread.sleep(9999);
		t2.start();
		Thread.sleep(10000);
		getJFileChooser();
	}

	static JFileChooser getJFileChooser() {
		long startTime = System.currentTimeMillis();
		System.out.println(Thread.currentThread().getName() + " :: Before new JFileChooser()");
		JFileChooser ret = new JFileChooser();
		System.out.println(Thread.currentThread().getName() + " :: After new JFileChooser(), instance: ["
				+ Integer.toHexString(System.identityHashCode(ret)) + "], took ["
				+ (System.currentTimeMillis() - startTime) + "] ms.");
		return ret;
	}

	public static class MyThread extends Thread {
		public void run() {
			getJFileChooser();
			try {
				Thread.sleep(10000);
			}
			catch (InterruptedException e) {
				e.printStackTrace();
			}
			getJFileChooser();
		}
	}
}
-------------

This outputs:
T1 :: Before new JFileChooser()
T1 :: After new JFileChooser(), instance: [1dd7056], took [9000] ms.
T2 :: Before new JFileChooser()
T2 :: After new JFileChooser(), instance: [1d63e39], took [265] ms.
T1 :: Before new JFileChooser()
main :: Before new JFileChooser()
T2 :: Before new JFileChooser()
main :: After new JFileChooser(), instance: [1df280b], took [547] ms.
T2 :: After new JFileChooser(), instance: [b23210], took [610] ms.
T1 :: After new JFileChooser(), instance: [42552c], took [8000] ms.

Note how T1 consistently gets slow instantiations, while the other threads (both T2 and main) have "lightning" performance. Basically, you get something along the lines of "inverted threadlocal caching" of the instances: all _other_ thread gets a consistent speedboost after an initial instantiation! Note that if you comment out the Thread.sleep(9999), then you still get this effect: The first thread that starts to instantiate the JFileChooser will apparently forever after have slow performance, while all others have fast.

I don't get that.

PS: Note that the stacktraces mentioned in bug 5033747 are exactly the same as posted here.

PLEASE try to fix this for Mustang.  It's costing me customers.

This has been a problem since Java 1.4 at least.. sadly several of the previous bugs complaining of performance were closed without actually fixing the performance issues!

Please don't close this without fixing first fixing it.  Every other time this problem has been reported, it's been closed as not reproducible or duplicate of another.  I'm using 1.5.0_06-b05 and it most assuredly is still a problem there.

Note for reproducing: The bug seems to be related to the number of files in the work directory. You need a lot of files to make sure you can reproduce it.

Thanks for reporting this. I described my problem here:
http://forum.java.sun.com/thread.jspa?threadID=747060

since I was assuming a defect in my installation somewhere. Interestingly, the call to new JFileChooser(), or to be more exact, line 424 of MetalFileChooserUI (1.5.0_07):

File[] cbFolders = (File[])ShellFolder.get("fileChooserComboBoxFolders");

doesn't return at all. The CPU Hangs with 100% even if I let it go for a quarter of an hour. Setting _fixChooser  to true eliminates the problem, the other settings don't show any effect at all.

With respect to the last hint, I will try to eliminate the number of files in my work directory and see if this has any effect. 

The time differs between 1 and 45 seconds, even with only some 10 files in the folder. Seems to have an integrated random generator. This applies only to the first instantiation the VM does, subsequent instantiations are fast.

I'm seeing this problem too--but it's taking 3-4 MINUTES before the dialog pops up.  Maybe this is a different bug, it's just started taking so long.

More info from submitter (to whom, btw, the name "Nelson" means nothing!):

Okay, I think I'm on to something: It most probably have something to do with the amount of _compressed files_ (zip, rar) on Windows' Desktop (this even if "My Documents" or another folder is where the JFileChooser is set to open).
   Do however keep in mind that the "inverted threadlocal caching" still holds: the first thread that does a new JFileChooser forever gets really slow performance, _while all other threads_ have really fast performance throughout (even before the first Thread have actually returned from the new JFileChooser invocation).

I've hopefully pretty much verified the compressed files theory by moving away all files from the Desktop, in which case the JFileChooser came up pretty much instantly, then moving back the compressed files (zip and rar), and it instantly took several minutes to appear (even if I didn't restart the JVM in between, I just hit the "add files" action again in an application I happened to have open here; JPO), and then moved those away, and instead moved back all the other files and directories (of which there are many more than these zips and rars) - and it's back to fast operation. (Btw, if for some reason it has anything to do with anything, WinRAR is installed on my box, and it is set to open most compressed files)

Using the excellent Process Explorer from Sysinternals (http://www.sysinternals.com/Utilities/ProcessExplorer.html), I found that there is one Thread of the java-process in question that takes over 90% CPU, and that thread is apparently the same thread as my "fixer-thread" described above, as it disappears when the new JFileChooser constrcutor finally returns (and thus the fixer-thread exits).

The "Process Details" view a process in ProcExplorer allows you to get thread listing, and also to get the stacktrace of each thread. There is apparently happening a lot, but I've included some stack-traces that are very typical during the 2-3 minute lock-up. Note the "entry-method" "sun.awt.shell.Win32ShellFolder2.getAttributes". Note that I'm pretty much always seeing the same trace up to "zipfldr.dll+0x100f5". Note also in particular that the "CSwitch Delta" counter of the Thread view consistently shows around 1500-3500 switches per second for the thread in question!

(Sorry for not actually profiling this properly, but I'm still not that proficient with native stuff on Windows..)

ntoskrnl.exe!ExReleaseResourceLite+0x2b4
ntoskrnl.exe!IoPageRead+0x892
hal.dll+0x2ef2
kernel32.dll!GetVersionExW+0x56
kernel32.dll!CompareStringW+0xab
kernel32.dll!lstrcmpiW+0x20
zipfldr.dll+0x100f5
zipfldr.dll+0x1029f
zipfldr.dll+0xaaab
zipfldr.dll+0x7c0e
zipfldr.dll+0x8117
SHELL32.dll!SHGetFileInfoW+0x3e38
SHELL32.dll!Ordinal646+0x5e1
SHELL32.dll!ILFindChild+0xc27
awt.dll!Java_sun_awt_shell_Win32ShellFolder2_getAttributes0+0x33
jvm.dll!AsyncGetCallTrace+0x2b75d


ntoskrnl.exe!KiDispatchInterrupt+0xa7
kernel32.dll!FindAtomW+0xd729
kernel32.dll!CompareStringW+0xab
kernel32.dll!lstrcmpiW+0x20
zipfldr.dll+0x100f5
...

ntoskrnl.exe!KiDispatchInterrupt+0xa7
kernel32.dll!FindAtomW+0xd98f
kernel32.dll!CompareStringW+0xab
kernel32.dll!lstrcmpiW+0x20
zipfldr.dll+0x100f5
...

ntoskrnl.exe!ExReleaseResourceLite+0x2b4
ntoskrnl.exe!IoPageRead+0x892
hal.dll!HalClearSoftwareInterrupt+0x342
kernel32.dll!GetVersionExW+0x26c
kernel32.dll!CompareStringW+0xab
kernel32.dll!lstrcmpiW+0x20
zipfldr.dll+0x100f5
...


It might have something to do with the zip-folder feature of Windows? But do still remeber the extremely strange effect where only the first Thread that constructs a JFileChooser gets the hit - thus it is not as easy as to point the finger at the zip-handling of windows or something similar, since all other Threads have totally acceptable performance!

BTW: why is the bug comment window only 4 lines big??

This is the stack trace I see on my 3-4 MINUTES bug:

ntkrnlpa.exe!KiUnexpectedInterrupt+0x121
ntkrnlpa.exe!NtWaitForSingleObject+0x9a
ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb74
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
jvm.dll!jmm_GetLastGCStat+0x6964

(re: my comment which was posted on Aug 2)

More from submitter.. :

I now realize that this bug most probably is the same as bug #5050516 - they indeed profiled it down to the zipfolder support in XP.

There are several bugs in the bug DB that _screams_ about slow performance for the chooser (and Sun just closes them?!), and they all seem to be "not consistently reproducible". It may be because people have different amounts of compressed files laying around in their folders? Also note that I get this slow performance throughout the chooser not depending on the "initial dir", but seemingly depending on the amount of compressed folders laying on the Desktop ("C:\Documents and Settings\<user>\Desktop")

So, bug #5033747, bug #5050516, and also comments around in other JFileChooser bugs ("It takes 5 minutes to just instantiate the JFileChooser!!") seem to point at the same problem..

(I'd still like to stress the point that only the first thread that does a new JFileChooser() construction gets the extremely slow performance - all other threads are actually quite performant.)

Thanks for the last comment.  I found that the delay was caused by a few large zip files on my windows XP desktop, and if I simply created a folder called "zipFiles" and hid them in there, I get no delay at all when a JFileChooser is created.

Somehow I didn't come across bug report 5050516 when I first encountered the problem.  Clearly that's what was going on.

Well.. I've confirmed that large zip files on my Desktop where causing the issue. it could be listed as a work around. I've also tried completly disabling "zipfolder" feature in windows by commandline:
regsvr32 /u %windir%\system32\zipfldr.dll 
which resulted in same improvment.

btw send:
regsvr32 %windir%\system32\zipfldr.dll
to re-enable zipfolder feature.

I'm developing a work around as follows:

We made a ShellFolderManager2 class that extends Win32ShellFolderManager2.  It overrides one method and uses a little bit of reflection so it does exactly the same thing the existing class does, but it does NOT call isDirectory() on files that end in ".zip".

It's definitely a hack, but [pending more testing] it appears to be a big improvement.  I'd love to get some feedback on it (both in testing and in general design); contact me if you're interested.

I confirm the result's of Endre's investigation. Large compressed files are the couse of the problem.

I also can reproduce, by and large, the findings here.  If I move all of the zip files on my desktop into a folder, the time to open JFileChooser is greatly reduced.  Also creating a JFileChooser on the main thread before instantiating the gui causes a one-time delay and fast instantiation of any JFileChoosers on the EDT.  And as noted in the first comment, the delay can be avoided altogether by instantiating JFileChooser after scheduling the gui to run.

I am now using the following code (single-thread rule be damned):

    public static void main (String args[]) {
    	long t = System.currentTimeMillis();
    	
        EventQueue.invokeLater(new Runnable() {
            public void run() {
            	createAndShowGui();
            }
        });
        System.out.println("gui builder dispatched, t=" + (System.currentTimeMillis() - t));
    	
        new JFileChooser();
    	System.out.println("JFileChooser instantiated, t=" + (System.currentTimeMillis() - t));
    }

Here is a typical result:
     [java] gui builder dispatched, t=297
     [java] JFileChooser instantiated, t=14469

By the time "JFileChooser instantiated" rolls up on the screen, I can be already editing a file opened in my application using a JFileChooser created on the EDT.  As I mentioned above though, this runs gui code on the main thread after the EDT has started, which could cause all sorts of wailing and gnashing of teeth that I don't know about.  Can anyone comment on whether this could be a problem?

So I would ask, if you call setDirectory() on the chooser, to a directory without compressed files, does that stop this from happening?  I'm curious why the desktop folder's contents create the problem, or if that is just the folder that you all are opening.

> So I would ask, if you call setDirectory() on the chooser, to
> a directory without compressed files, does that stop this
> from happening?  I'm curious why the desktop folder's
> contents create the problem, or if that is just the folder that
> you all are opening.

See the drop-down box at the top of the file chooser?  No matter what folder you start at, it always has to render that drop-down, so it will always be slow.

Is there some good way to use the native file chooser?  Swing's one looks like Windows XP but I'm not running XP anymore.  Sometimes I feel it would be easier for Swing to just use the native one so that when the user updates Windows they get the new style without Sun having to add support for it.

I had a big zip file (open jdk 7) on my desktop and my JFileChooser took ages.  Note that for me, when I ran my program from Netbeans there was no delay, it was only when I double-clicked the jar file or ran the web-started program that I got the massive JFileChooser wait time.  Maybe this is why the SUn enginieers can't reproduce the problem - it only happens when the program is run from the jar file (perhaps this has somehting to do with running it from javaw.exe rather than java.exe???).

Thanks for sharing the zip-file clue.  Regards,
Keith

Like Keith, I only experience the problem when I package the application in a jar file and run it from there. I've btw tried to remove all zip files from the desktop, but without effect. I'm running Java 1.6.0_02. I experience a 15 second delay each time I change folder in the JFileChooser dialog. I tried the same thing on two other computers, and the problem appeared on one of them.

/Johan

I find that this bug seems to be fixed in 1.6.0_01, but reappears in 1.6.0_02 and _03.  Also, in addition to archives on the desktop causing slow JFileChooser startup, traversal of any directory containing large and/or many archives is also poorly responsive.

I had an extremely slow File Chooser when using Netbeans (5.5.1) or any recent Java based tool (older tools seems to work fine).  I had a lot of files on my desktop (100+), including zip files. I removed all these files and "miracle" the 30 sec+ delays when navigating directories have now vanished! Serious bug here!

As noted in my last comment, this bug does not exist in 1.6.0_01.  When I compared the Win32ShellFolder2 source for _01 and _02, the difference became apparent.  There are two static internal classes added to the _02 version (COMTask<T> and COMTaskExecutor) which are used extensively throught the Win32ShellFolder32 code.  Basically, many operations that used to take place on the "current" thread are now being executed on a "COM" thread.  Many of these newly threaded calls are to native methods, particularly initDesktop, initSpecial, etc.  I'm sure someone at Sun could see what's going on here pretty quickly.

I have the same problem with JFileChooser (too slow open the dialog and to open any folder). It appear in my app when i updated my VM to last version. Now i have the version 1.6.0_03, and I've this problem.

I think that this is a high priority bug.

This is likely to be duplicate of 5050516 (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516) and caused by fact that:
 1) JFileChooser tries to read directory content in the constructor
 2) Directory contains large archive files and it mistakenly 
triggers scan of their content (scan is performed by windows but it requires unpacking and it is slow)

Workaround is to avoid large archives on desktop or install 
external archivers that will prevent Windows from treating archives as compressed folders.

Does this issue still exist in Java 6 Update 4?

I cannot grasp those idiots that post "I don't find the same thing happens with me, I however have this completely different problem here blah blah".. 

WHY DON'T YOU GO MAKE YOURSELF ANOTHER BUG REPORT, THEN??? 

Don't litter this bug with piss info.

Managed to reproduce the bug quite easily:
1. put a large zip file to the desktop.
2. new JFileChooser() in main()
OS is Windows Vista x64 SP1 RC, JDK is 1.6.0_04, so it is not fixed in update 4.
A small investigation of the problem (source code availability is really pleasant is such cases):
Method which is causing the bottleneck is Win32ShellFolderManager2.get("fileChooserComboBoxFolders"). More precisely, the delay occurs when  Win32ShellFolder2.isDirectory() method is invoked for a zip file. This results in 3 subsequent calls to COM method IShellFolder->GetAttributesOf() (which, by the way, is a bit suboptimal). So the zip file is tested for 3 attributes: SFGAO_HASSUBFOLDER, SFGAO_FOLDER and SFGAO_BROWSABLE. The first test (for SFGAO_HASSUBFOLDER attribute) is the one which takes a lot of time, as it requires unpacking of the zip file.
Most workarounds I can imagine were already identified here. I think this 3 are the easiest ones:
1. regsvr32 /u %windir%\system32\zipfldr.dll (normal people are using corresponding software, so this Windows feature is not needed anyway)
2. Remove zips from your desktop (which is also reasonable, desktop is a place for shortcuts, not for archives).
3. putClientProperty("FileChooser.useShellFolder", Boolean.FALSE);
The easiest fix would be to test first for SFGAO_FOLDER, this test returns true for zips, so the long test for SFGAO_HASSUBFOLDER would be avoided. But, as stated in bug 5050516, the test for SFGAO_HASSUBFOLDER is not necessary at all, as test for SFGAO_FOLDER attribute is sufficient to determine if the item is a folder. So this bug is same as 5050516 and can be closed as duplicate.
I did a check in SVN repository with source code snapshotes for JDK6/7. The bug is fixed in JDK7, but it is not yet fixed in JDK6. So if anyone needs this bug fixed urgently, you better press to have 5050516 in the next 1.6 update.

There is *no* question that this needs to be addressed in the next Java 6 Update!

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516 fixed in update 10.

If you're stuck with jdk5, you could also use VFSJFileChooser(http://vfsjfilechooser.sf.net). It's built on top of Apache Commons VFS. As VFSJFileChooser doesn't call win32 api, the bug doesn't appear.
You could also use VFSJFileChooser if you need file system abstractions(Local files, FTP, SSH, WEBDAV, Windows LAN/Samba). You can remove any jar dependencies for other protocols if you don't need them.

Heads up for anyone looking at this bug my experience has been a bit different. 

Instead of taking a "long time", the program I am using simply freezes when new JFileChooser() is called, one processor jumps to about 85% and stays that way for several minutes, memory use steadily increases to over 100 meg. 

I am using build 1.6.0_07-b06 on vista 64, not sure which version of vista.

@PeteCarapetyan: Did you read any of the other posts in this bug? Specifically the one five posts up from yours that I made pretty much exactly a year before you? I'll repeat it here again for clarity:

" I cannot grasp those idiots that post "I don't find the same thing happens with me, I however have this completely different problem here blah blah".. 

WHY DON'T YOU GO MAKE YOURSELF ANOTHER BUG REPORT, THEN??? 

Don't litter this bug with piss info. "

Workaround putClientProperty("FileChooser.useShellFolder", Boolean.FALSE);
seems to cause InternalError in release 14. 

I just installed build 1.7.0-ea-b59 hoping it has the fix but I still experience slow JFileChooser browsing on remote network folders, the more files the slower. The bug is clearly still there. I am using Windows Vista. 

The interesting thing is that my other computer running Windows XP and 1.6.0_03 doesn't have this problem

Installed 1.6.0_01 (like some comments suggest) and it doesn't help. Just to clarify something, I don't have any ZIP files in my folders. The time is a few seconds, the more files the longer it takes (opening a folder with 20 files takes around 10 seconds).