JFileChooser takes much time to instantiate and to browse large folders. In comparison with 6u1, performance degraded significantly.

The issue was initially reported at http://www.javalobby.org/forums/thread.jspa?messageID=92159440
Posted Date : 2007-07-12 18:31:03.0

N/A

I profiled it and found 3 major bottlenecks:

a) frequent calls to Win32ShellFolder2.isFileSystem() and Win32ShellFolder2.isLink(). The both methods invoke hasAttribute() that in turn delegates execution to the COM thread.

b) frequent calls from BasicDirectoryModel.LoadFilesThread to various Win32ShellFolder2's methods delegating execution to the COM thread.

c) frequent calls from FilePane.DetailsTableRowSorter to Win32ShellFolder2.ColumnComparator.compare() on file sorting, also delegating execution to the COM thread.
Posted Date : 2007-07-12 17:51:21.0

For the SDN community
Please note that this CR doesn't address the ZIP issue, it rather concerns overall performance degradation after the COM fix (see CR #6491795). For the ZIP issue, there's a special CR #5050516. You can find links to the both mentioned CR's in the 'Related CRs' section on this page.
Posted Date : 2008-03-19 12:10:21.0

This bug is a cause of fix of CR 6491795. Closed as "Not reproducible" because the fix of CR 6491795 for jdk7 contains fix of this CR as well.
Posted Date : 2009-03-18 17:11:53.0

Please ensure that JFileChooser does not invoke isFileSystem(), isLink() etc on items outside the current directory view. Specifically it should not invoke these on all network drives and all files in the desktop directory.

Any update? Will a fix for this be rolled into update 3?

Oops, last post was by me.

Not mentioned yet, but I observe the same performance degradation in webstart on  javax.jnlp.FileOpenService.openFileDialog()

Please can you fix this bug as a matter of priority since there doesn't appear to be a convenient workaround and the performance is unacceptable on my machine, simply opening the dialog takes ~25 seconds and browser incurs similar delays.

It would be nice to have an update on what's happening with this bug.   It really makes the latest version of Java totally unusable for a significant percentage of users. 

As already mentioned, this bug kills 6u2 on Windows. Lot's of applications become de-facto unusable. We need to roll back all customers to 6u1 or 6.
Looks like access rights are part of the problem, because the problem does not seem to be as hard when run as Administrator(s).

This bug is a real DISASTER. It's really annoying after all to watch 6u3 beeing passed and widely advertised with this bug. 95% of Java desktop users are Windows users and still, 6u3 is on your site. One could think that some SWT spies got into Swing team :-). This bug is also a blow towards beautiful Netbeans 6. It would be much more onest and useful to to take buggish 6u2 and 6u3 away until they are fixed and return to 6u1.

This BUG HAS to be FIXED.  We have a Java Web Start application that has a few features that require browsing directories and choosing files.  This is unusable in 6u2 and 6u3.

I was able to prove that in my case the stumbling block for JFileChooser was a large ZIP file (approx. 1 GB) on the 'Desktop' (see also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516). Although the file chooser was not even browsing the Desktop folder (but 'My Documents'), the dialog opened nearly instantly after moving the ZIP file away (to C:\).

I can confirm the problem about ZIP files on the desktop, but even two or three  100M zip files is enough for a complete 30 sec. break. And this is a regression from 6.0 or 6u1, no change between 6u2 and 6u3.

This bug should have been fixed on 11-JUL-2007 (1 day after it was reported).

Everyone, please vote for this bug !!!

Another confirmation: Instantiating JFileChooser dialog took 1 minute on my machine. I removed all ZIP files from the desktop and speed was back to normal. The JFileChooser was NOT opening to the desktop and I still have big ZIP files lying around, but not on the desktop. It has something to do with the ZIP folder feature of windows XP, since deactivating that feature also does the trick: regsvr32 /u zipfldr.dll (regsvr32 zipfldr.dll to reactivate). PLEASE fix this fast!

Using a file filter to omit zip files seems to workaround the issue for me.  
This works for me since the application does not open or save zip files.

class NoArchiveFileFilter extends FileFilter {
          public NoArchiveFileFilter() {
          }

          public boolean accept(File f) {
            return !f.getName().endsWith(".zip");
          }
          
          public String getDescription() {
            return "No archive files";
          }
        }

Confimation N+1.

Zip files on desktop, slopped them all into a folder and the problem went.

My app uses zipped xml files as data, and it doesn't have this problem accessing folders with these in. These zips only have 1 xml file each, so perhaps another indicator it's the number of entries in a zip that's the problem.

I thought NetBeans 6 was utterly and hopelessly broken in terms of performance until I realized it was actually this bug showing up since I'd left a large zip on my desktop.

This must be fixed ASAP.

I have the same bug on my machine / win XP, this is a DISASTER for any Swing applications (JProfiler,...), we can't use Java 6U3, we stay in Java 5 due to this bug Please FIX IT in priority !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Thank you.

This has nothing to do with zip files.  I get an enormous delay opening an empty folder

I also have run into this bug on Windows XP.  I "fixed" the issue by disabling ZIP support in XP following the directions in the following link.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516

I confirm that disabling the zipfldr.dll on XP is a workaround... but not for my end user customers !!!!
This bug (and the related ones with network drives: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6317789, broken links file) is very very annoying and has been existing for a long time...

Please, fix it in priority.
Many thanks 

This bug reinforces the viewpoint that Java is not suitable for desktop applications.  One of the most common dialogs takes up to a minute to open!  The only conclusion my colleagues can draw is that Java is not an option for real desktop apps.

Please, please fix ithis bug  in the next build for Java 6.  Waiting for java 7 will be deadly.

Whoever submitted the entry that says "...This bug reinforces the viewpoint that Java is not suitable for desktop applications..." should do a little homework before making narrow-minded comments.  I too experienced the problem and decided to stick with Java 6 update 1 because it doesn’t appear to exhibit the problem.  Java, not being perfect, is a great solution for desktop applications, especially if you use the Netbeans Rich Client Platform  (platform.netbeans.org).  I have vast experience in writing RCP applications in several languages (i.e. Java/Swing, Visual Basic, Delphi, C++ Builder, Win32 API, Tcl/Tk, etc…) and all have their strengths and weaknesses.  Ultimately, I chose Java and Netbeans 6 platform because of the out-of-box features, cross-platform support and most importantly, it has great community support.  Instead of bashing Java, why don’t you try and get involved.  After all, if you are a Software Engineer or Programmer, your job is to solve problems, not complain about them.  Finally, now that Java is an open source community project, we all benefit from making it better, so please keep that in mind.

End-users don't do homework.  They use whatever JVM version they have around.  If that has a bug like this, then they scream at the product and/or Java -- and are unlikely to give either of them another try.

NetBeans itself is *horribly* impacted by this bug and lots of users have screamed about it.  [Personally I removed zips from my desktop and avoid File/Open dialogs -- I'm not moving back to update 1.]

This bug is marked as fixed in 6u4 version. I've just downloaded and installed that version on my Win XP. The FileChooserDemo works as badly as in earlier version! The bug seems not to be fixed!!! Opening the C:\ directory takes about 10 minutes with 100 % cpu load. The same action with jdk 1.4.2_03 (also installed on my machine) takes less than 1 second! This bug makes java 6 with desktop aplications  almost unusable. 

I notice a major improvement! thanks guys!

I am also still experiencing very slow JFileChooser with 6u4/win xp when zips are present on desktop. 

Looks like bug is not fixed after all.  In a prior message, I responded to this post from a developers viewpoint where I have control over which version of Java my end-user applications run on.  However, from the end-user standponit where the version of Java is auto-updated, I agree that this bug makes Java look like a horrible solution for desktop applications.  So, for those who use the auto-update system, this bug should get resolved ASAP...

Fix ASAP!!!  You've no idea how bad it looks to users.    There have been so many speed regressions in the swing dialogs on windows that you need some kind of test (manual, if necessary) for each release/update to make sure this it continues to work with large directories (1000+ files), over networks, with very large files, etc...

In spite of enormously destructive effect of the problem to  JAVA image, the management behaves as arrogant ostriches, pretending for 1/2 of the year that it's just a minor fault that could be adjusted somewhere in the future. Such greedy illegibility kills the common sense. Would you buy an 8-cylinder sports car where one of them doesn't work? I would prefer a bicycle.

I have just done a quick test (running with XP, Professionnal, SP2 + JDK 1.6u4). (1) many ZIP files in my C: drive = 5 mn to list files+repositories into C: with NetBeans, (2) after moving those ZIP files away, the C: file listing is quite instantaneous. Before discovering this bug, I have killed many times NetBeans thinking about into NetBeans... Please, browsing the file system is a basic feature and should available at reasonable speed.

We ran a test where JFilechooser accessed a remote drive, before update 4 this took about 45 sec. now it takes about 2 sec. so definitely an improvement. 

In the evaluation of this bug I don't see anything  mentioned about handling of zip files, so isn't the zip-file bug more addressed in?:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516

Still broken for zip files.  The other bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516
has been marked as closed.  Please fix it, as it is taking minutes to launch an application due to the presence of large directories and zip files.

Just had some code doing

private static File locate(String key) {

    JFileChooser jfc = new JFileChooser();
    jfc.setDialogTitle(NbBundle.getMessage(Povray.class, key));
    jfc.setFileSelectionMode (JFileChooser.FILES_ONLY);
    jfc.showOpenDialog(WindowManager.getDefault().getMainWindow());

    File result = jfc.getSelectedFile();
    return result;
}


I have found it EXTREME slow when I navigate all the way to C:\  

THIS IS STILL THE CASE FOR 1.6.0_05 !!  

WORKAROUND:  As earlier suggested, disabling ZIP support with

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

FIXES the problem.

... the reason was I had a 400Mb ZIP file under C:\

So - to reproduce: Create a big zip file (400MB) and place it in C:\  now try to navigate to C:\ with your fileChooser ... oops

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516 tells about the update 10 fixing this bug.

A few java desktop apps I used has experienced lags for opening files on jdk 6u4. After removing a 68M zip from My Documents, the lag disappeared. Please have this fixed!

jdk1.6 u10 does not fix this issue, i had to disable windows zip support to fix it

Because of this bug, openen projects and files in netbeans is also very slow and processor-intense (50% of processor-time and more)

This bug is nothing short of incredible. It DOES incredible damage to java for the desktop (To Mr "longstrb ", I have only 2 sentences : Puh-LEASE! Your self-confessed brilliance is completely irrelevant to this problem.)

Sun has essentially broken Java 6 on Windows XP (at least). If I were like longstrb  I'd launch into a paean of how I used Linux exclusively for since 2008 until recently, but then that would be irrelevant.

Sun : Look to your products and fix this without messing around anymore. It's embarrassing to have told people for the last 8 years that Java is solid, when you can't even keep the basic file-browsing functionality working on Windows.

No. It's not fixed even in 1.6.0_07 (6u7). There are some improvements but still not as fast as in Java 1.4.x, if you consider that showing a directory with just 20 files (around 70M) takes over 10 seconds.

I'm the last commenter (Submitted On 29-JUL-2008). It seems that it is fixed in 6u10. At least, file browsing is as fast as in 1.4.x. Well done.

I have the latest JRE, 6u7, and in Vista x64 my JFileChooser cannot display the contents of a folder containing 3000 folders. My XP x64 PC can do it no problem. Please look into this!

We bumped into this recently and couldn't believe our eyes. Why hasn't this been fixed and closed?

OMG over a year and not fixed? Are you kidding me? I would use .NET over this crap.

Microsoft has in fact, at last, won the java battle.

All they had to do is wait for Sun to shoot themselves (and us) in the foot. With a bazooka.

Nice job Sun! At last you've made Java the equivalent of Sun itself - bloated and abysmally slow. I feel sick for all the effort I've put into the Java ship, now that you've run it aground.

All aboard for the .NET-town and ActiveX.

Jeez - you guys are just un-be-LIEVABLE. 

How arrogant you are at SUN ?
No one get on the Knees that this will fixed, we simply left. 
We now have 6u11 and nothing seems to be fixed.

3 years and not fixed! http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6372808

I dont know what is happening, but it seems Swing is being left aside... When I use Java to program it is 99% Desktop programs using Swing. If Sun lefts desktop programmers aside I will left Sun aside too.

I was programming in Java for 5 years and now I had to learn Python because of my job. I think Python will be my favorite language for now on...

Sun, please fix this bug.
Many users complain they can't save their work in Sweet Home 3D, and I'm sure it's because of this bug.

This bug has deteriorated the performance very much. 

should I wait for a long time?(>o<;)

166 votes and Sun closed it for "Not Reproducible" reasons. I'm amazed !!! 8)

Same problem here. Large zip-file in desktop causes filechooser to slow down significantly (takes one minute and more to open)

PLEASE REOPEN !!!!

Dear schlm3,

You are talking about another bug. Please take a look at the bug # 5050516 (JFileChooser very slow in XP if directory contains large zip files). That bug was fixed, see details in the bug description and comments... Compare your jdk version with the jdk that contains the fix.

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.