JFileChooser still very slow in JDK 1.4.2-02 (re Bug Id 4712307)

Thread view:

Jim Cobban - 11 Jan 2004 20:32 GMT

According to the Java Bug Database (Bug Id 4712307) the problem with
excessively slow JFileChooser is supposed to be fixed in 1.4.2. However I
still find it takes eons to display even a very small directory.

How do I find out what is going on to solve this, since Sun keeps closing
the problem?

Signature

Jim Cobban jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438

Reply to this Message

ak - 11 Jan 2004 23:26 GMT

> How do I find out what is going on to solve this, since Sun keeps closing
> the problem?

unfortunately, this is not the first bug which was just closed without any
real action.

____________

http://reader.imagero.com the best java image reader.

Reply to this Message

Mark Thornton - 12 Jan 2004 19:24 GMT

> According to the Java Bug Database (Bug Id 4712307) the problem with
> excessively slow JFileChooser is supposed to be fixed in 1.4.2. However I
> still find it takes eons to display even a very small directory.
>
> How do I find out what is going on to solve this, since Sun keeps closing
> the problem?

Are you sure it isn't the OS itself? Some directories take an age to
enumerate in Windows Explorer. I think the problem is retrieving the
existence, status, icons etc for some of the special items. The addition
of a backup app has caused the enumeration of the local machine folder
on my (XP) machine to take ages on the first occasion.
There isn't a lot that Java can about this.

Mark Thornton

Reply to this Message

Jim Cobban - 12 Jan 2004 21:35 GMT

> Are you sure it isn't the OS itself? Some directories take an age to
> enumerate in Windows Explorer.

If that were the case then it would take a long time to see the contents of
this directory in Windows Explorer. But that is not the case. There are
only about 50 files in the directory, and Windows Explorer displays them
almost instantly. It is only JFileChooser which takes a long time.

As I understand the description of the latest "fix" for Bug Id 4712307 it
improves performance, but only if you have not put in a custom file filter.
That is the fix appears to be that if there isn't a custom file filter then
JFileChooser issues a single call to the Win32 API to retrieve all of the
information, and then formats it. If there is a file filter it issues
multiple calls to the Win32 API. However a JFileChooser without a custom
file filter is not a terribly useful object in most applications.

If the performance hadn't been excellent in 1.3.1 I wouldn't make a big
issue of this, but there has been an extraordinary degradation in the move
to 1.4. It takes orders of magnitude longer to display now.

Reply to this Message

JFileChooser still very slow in JDK 1.4.2-02 (re Bug Id 4712307)

Free Magazines