United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4712307 : JFileChooser is very slow when browsing many files in a directory

Details
Type:
Bug
Submit Date:
2002-07-09
Status:
Resolved
Updated Date:
2003-10-08
Project Name:
JDK
Resolved Date:
2003-02-25
Component:
client-libs
OS:
windows_98
Sub-Component:
javax.swing
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.1
Fixed Versions:
1.4.2 (b17)

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

Sub Tasks

Description

Name: jk109818			Date: 07/09/2002


FULL PRODUCT VERSION :
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)


FULL OPERATING SYSTEM VERSION :
Windows 98 [Version 4.10.2222]

A DESCRIPTION OF THE PROBLEM :
Using the file chooser, browse to a directory with many files,

the dialog takes a long time to show.  After it shows, it
will takes a long time to show the files.

The folder I tested with has:
1545 files and 49 folders.  Note that Notepad.exe open this
instantly.

There is a related bug that is closed:   4621272
It says that it fixes the bug in hopper, unfortunately, I
have no way of knowing if j2sdk1.4.1 beta is "hopper" or not.

Also, note that the 2 bugs are different.  The related bug
show slowness when select many files.

This bug shows slowness by merely open a directory.

Also note that with j2sdk1.4.1 beta, the previous bug is
still there, and select 1 file, the select another file,
there is a long pause between (inconsistently though, and
only happen in a directory with many files - note: just
select 1 file, not many files).



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Run the application
1) Open a JFileChooser
2) Browse to a directory that has many files
 (it's even better to have the first directory of
JFileChooser to have many files to show the effect of slowness).

EXPECTED VERSUS ACTUAL BEHAVIOR :
Things work faster.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.io.*;

public class BugDemonstration
{
	public static void main(String args[])
	{
		final JFrame frame = new JFrame("The Frame");
        frame.setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);
		frame.setSize(200,200);
        frame.setVisible(true);

        SwingUtilities.invokeLater(new Runnable()
        {
            public void run()
            {
                JFileChooser file = new JFileChooser();
                file.setMultiSelectionEnabled(true);
                file.setDialogTitle
                    ("Select lots of files..." );
                file.showDialog(frame.getContentPane(), "Demonstrate problem");
                File [] selected = file.getSelectedFiles();
                System.out.println (selected.length+" files selected.");
            }
        });
    }
}
---------- END SOURCE ----------
(Review ID: 158588) 
======================================================================

                                    

Comments
EVALUATION

The problem has been solved through a number of improvements in
filechooser and shellfolder code. Primarily, the trick was to
no longer separate the codepaths in Win32ShellFolder between
fileystem objects and special shellfolders, but instead take
advantage of the Win32 Shell API to get all the information
we need. By totally avoiding any loops hitting the java.io.File
class for information (such as exists() and isDirectory()) we
managed to speed things up by several 100 x.

There were also some improvements made in the efficiency of
filechooser loops. These changes will also benefit other platforms
than win32. See also the evaluation of bug 4679673.

Note: In case the new changes should cause new problems (regressions)
in 1.4.2, the bugfix can be turned off by adding the following switch
to the command line: -Dswing.disableFileChooserSpeedFix.

###@###.### 2003-02-13
                                     
2003-02-13
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis-beta
tiger

FIXED IN:
mantis-beta
tiger

INTEGRATED IN:
mantis-b17
mantis-beta
tiger


                                     
2004-06-14



Hardware and Software, Engineered to Work Together