JDK-4395239 : JFileChooser setup performance bad
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.0
  • Priority: P5
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-12-05
  • Updated: 2013-11-01
  • Resolved: 2003-07-22
Related Reports
Relates :  
JDK-4260746 - JFileChooser-dialog wait for timeout if there is no access to connected client
Relates :  
JDK-4282775 - Poor performance when loading JDialog/JFileChooser the 1st time
Description

Name: yyT116575			Date: 12/05/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)


There are many bugs relating to the JFileChooser.  Many
have evaulations saying essentially that the problem is
with timeouts in the OS (in my case WinNT).  The problem
I have is that there should be a way to query the OS
without actually doing something that would enter into
a timeout type situation.

On a HP OmniBook 4150 bringing up a new JFileChooser takes
about 2 minutes to bring up.  The big wait seems to be a
timeout waiting on A:.  The bad part of this is that the
JFileChooser shouldn't care when it comes up what's in 'A:'.
Well, not until someone tries to open 'A:'.  A timeout is
expected then.

Even the native code in FileSystem.listRoots () seems to take
too much time.
(Review ID: 113271) 
======================================================================
Comments
WORK AROUND Name: yyT116575 Date: 12/05/2000 Grab source for MetalFileChooserUI FileSystemView add checks around 'A:\' that would slow it down unreasonably. Maybe add a 'Refresh Roots' button to tell the UI to rescan. ======================================================================
11-06-2004
EVALUATION This is a performace issue related to, but not identical to, bug 4260746. ###@###.### 2001-11-14 Not reproducible in 1.4.2. ###@###.### 2003-07-22
14-11-2001