Skip to main content

Will JFileChooser be fixed for Java7?

35 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24

Now that Java6 is out and Sun is working on Java7 can the Swing team please comment on whether there are plans to fix JFileChooser under Java7? I am expecting it to behave exactly like the native file chooser under Windows. Currently there are countless usability issues (even in Java6) such as:

1) Keyboard navigation using arrow keys sometimes stops working (this is due to some sort of focus problem).

2) Double clicking on a folder sometimes does nothing, sometimes goes into "rename" mode instead of navigating into the folder

3) Auto-completion for folder/file names

4) Hitting ENTER when a folder is selected should never close the dialog and return that folder, even in folder-selection mode. The native behavior is that a folder is only returned if the OPEN button is hit, hitting ENTER on a selected folder navigates into it.

5) Major performance problems. Double-clicking on a folder is far slower in the Swing interface (a matter of seconds) than the native interface (a matter of milliseconds).

I am hoping to hear commitement from Sun to (finally) see this fixed for Java7. In my view, JFileChooser is by far the most broken Swing component out there (with respect to the native L&F).

Gili

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ewin
Offline
Joined: 2005-07-15

First things first.

First you have to make the Swing team admit that the current file chooser is a POS. People have tried to drive this message home for a decade or so, but any argument was lost on the Swing team.

Once you managed to do this you could try to point them to the NB file chooser.

Good luck.

cowwoc
Offline
Joined: 2003-08-24

Looks like we might have an opportunity to get some fixes into JFileChooser due to a bug introduced in Java6 update 2. ewin and others, you might want to send your comments to Leonid's post on http://www.javalobby.org/java/forums/t98389.html?start=20

loneid
Offline
Joined: 2006-04-13

Hi,

> Looks like we might have an opportunity to get some
> fixes into JFileChooser due to a bug introduced in
> Java6 update 2. ewin and others, you might want to
> send your comments to Leonid's post on
> http://www.javalobby.org/java/forums/t98389.html?start
> =20

I keep reading this thread, too, so you can send your comments here. I didn't reply to suggestions to rewrite it from scratch because it (rewriting) is simply impossible due to various reasons.

If you want a known bug to be fixed sooner, please vote for it at http://bugs.sun.com/bugdatabase. We are also want to know what new features you'd like to be implemented in coming releases, so your constructive suggestions are appreciated.

Regards,
Leonid Popov
Swing team engineer
Sun MicroSystems

cowwoc
Offline
Joined: 2003-08-24

Hi Loneid,

I listed the major problems I found in the first post of this thread. I'm not sure I understand why a rewrite is not possible. So long as the public API remains backwards compatible could you not rip out the implementation and start afresh?

Gili

kirillcool
Offline
Joined: 2004-11-17

> I'm not sure I understand why a
> rewrite is not possible.

The sheer amount of features that need to be supported under multiple platforms comes to mind. Would you undertake to reimplement it from the scratch? If the answer is "no, i don't have time due to all this other things that are more important to me", the same would be (i guess, since i'm not part of Swing team) true for the other side as well.

lt401vette
Offline
Joined: 2008-10-12

I hope this thread was heard.
Java with swing is a great platform to write applications from, almost. The FileChooser problem drives me nuts!! The lack of a decent file dialog is clearly the weakest point in trying to use Java for desktop applications, It is the one thing that there is no solution for. Every time I deploy an app the the terrible file dialog behavior reflects back on me and there is no solution.

The awt FileChooser doesn't accept filters (at least on windows), can't multiple select and you can't even place it, it has to open in the top left of the screen. But at least once it is open it works on windows, but not so on Linux.

So try the swing JFileChooser, it has much better flexibility and serves most purposes well from a feature standpoint. But when you go to use it as an end user.....
The double click is all buggy, especially on linux. You try to drill into a directory and it keeps trying to rename the directory. Then we can go into the very slow disk reading and feature gaps to native. I can wait for features to catch up, but please make it work with double click and not take ridiculous amounts of time to do a list.

i30817
Offline
Joined: 2006-05-02

The gnome reader is outdated with the current one. I hope that they replace the current api with a wrapper of the native filechooser. It is really the only component that NEEDS to be implemented and is composite, so it makes sense to wrap it.

On linux/gnome what is currently driving me crazy is folder selection. Did you know that selecting folders you need to be INSIDE the folder? Basically select the folder, click ok, and click ok AGAIN.

Then there are those exceptions while using a shutdown hook, (one processor, 1 user task running, jfilechooser task canceled because of time out).

lt401vette You can fix the double selection problem in two(3) ways, one is the global double click speed in linux (that is ridiculous , and probably overridden by the native filechooser) - you can this with a java property (forgot which) and a file in your gnome home (forgot which). The other way is to make the filechooser read-only (a much better solution IMO - creating and renaming folders in the filechooser is just misguided.
You can do this in some look and feels by
[code]
UIManager.put("FileChooser.readOnly", Boolean.TRUE);
[/code]
before running swing things.

There are also problems with the wonderfull WindowsXP decision to parse zip files.
Just in case i added this to the start of my program (that already parses zip files, thank you very much Windows xp team).
[code]
//windows zip filechooser bug, disable reading zip files, if you can.
if (System.getProperty("os.name").contains("windows")) {
try {
new ProcessBuilder("regsvr32", "/u", "/s", System.getenv("windir") + "\\system32\\zipfldr.dll").start();
} catch (Throwable ex) {
Logger.getLogger(BookJar.class.getName()).log(Level.SEVERE, null, ex);
}
}
[/code]

sauvage
Offline
Joined: 2004-03-04

i30817, your tips are awesome !
This should be on frontpage of java.net for 3 months ;-)

i30817
Offline
Joined: 2006-05-02

You're better off thank sun for opening up the jdk. And pestering about this and other problems. Or if you're man/woman enough, fix it yourself.

swpalmer
Offline
Joined: 2003-06-10

> 5) swing always will be slower, it's drawing stuff
> itself.
> it slower then AWT (which uses OS native methods) and
> slower then native programs, that's the price you pay
> for portablity

There is no reason that the code in the OS must paint faster than the code in the JRE. Presumably the JRE code has access to the same drawing methods that the native widget has access to via JNI. If you draw a line or blit a bitmap there doesn't need to be any significant difference. Specially when we are talking about UI widgets that don't require super-fast painting to be well within the response time expected of the user manipulating them.

The number of files in the directory shouldn't affect the painting speed that much, since you only need to draw stuff for the files that are visible. I suppose to get the scroll bars correct you might need to know more. In any case Windows is particularly bad at this. For some reason it appears that Windows scans the directory hierarchy one level deeper than necessary resulting in horribly slow refresh times in file choosers and explorer windows. If anything, I would expect Java could do it faster by not being so stupid about it.

i30817
Offline
Joined: 2006-05-02

Any "slowness" problem of jFileChooser is on startup, and mostly on file IO, i'd guess.
As for the design many open source developers that tried to change the default JFileChooser funcionality complaim about it. As in this bug report i sent to the TrueZip project:
https://truezip.dev.java.net/issues/show_bug.cgi?id=12

cowwoc
Offline
Joined: 2003-08-24

> I guess the talk is about JFileChooser.
>
> In JDK 7.0, we plan to add support for native file
> dialog in Swing, as well as we will continue
> improving the existing JFileChooser, as we know it is
> not good enough so far.
>
> I would like to ask you developers, to vote for the
> CR's important for you at
> http://bugs.sun.com/bugdatabase/ , it will help us to
> fix them in the right order.
>
> Thanks for your interest!
>
> Leonid Popov
> Swing team engineer

Leonid,

Is there a BugParade issue associated with the aforementioned RFE?

Gili

cowwoc
Offline
Joined: 2003-08-24

Guys, the new file chooser in Netbeans 6.0 contains big improvements.

To be clear, it still isn't perfect, but it provides filename auto-completion and the ability to drilling into a folder by hitting ENTER while it is selected.

I'm hoping the Swing team will pick this up and fold it back into the JDK. Is there anything I can do to help make this happen? :)

Gili

blackbuddha
Offline
Joined: 2006-06-07

I might be wrong, but I think the slowness issue is related to the limited java.io.File.listFiles() implementation: great for 10 or 20 or 100 (or maybe even 1000 files), but utterly braindead for 10000 or a million files. The need to provide a comprehensive listing of all the files in a directory means that if I have a million files, I have to scan all of them for all their metadata (length, lastmodified, etc/etc) and despite the operating system and file system sales and marketing hype this will ALWAYS be an O(n) operation.

What java really needs is a lazy/asynchronous interface for accessing directory listings (maybe an Iterator that only actually hits the file system when you use the next() method), so the file chooser (and whomever else uses directory listings) can load quickly and then fetch all the file information without having to pause and wait for a complete directory scan. I've done trivial implementations that spawned processes and used either an ls (on Unix systems) or a "dir" (on windows systems) and you can open a million file directory without totally crushing your system. Translating that into an opendir() call (on Unix systems) or FindFirstFile/FindNextFile calls on win32 platforms can't be particularly painful to do: they already do something similar, it would need the iterative interface, but that shouldn't be terrible.

cowwoc
Offline
Joined: 2003-08-24

blackbuddha,

While I agree that there is a usefulness for a lazily-initialized access to directory contents I really don't think this is the underlying problem with JFileChooser. Opening "C:\Program Files" on my system which contains 134 folders (no files) takes multiple seconds. There is absolutely no good reason for this and while I don't have hard figures to back up my claim I suspect that File.listFiles() returns these 134 folders *very* quickly.

I would advocate someone actually profile JFileChooser instead of making guesses :) I still think the code needs a complete rewrite (because it is a mess) but at least this will give us a better clue of what to watch out for.

Gili

cowwoc
Offline
Joined: 2003-08-24

FYI: I just noticed that JFileChooser accesses all drives *every single time* you drill into a directory. I connected to a remote machine using Remote Desktop, ran JFileChooser on it and every single time I drilled down my local drive A would get accessed (because it is being shared across Remote Desktop).

Furthermore the bug report I linked to seems to indicate the bottleneck is in JFileChooser's instantiation whereas the problem I am reporting has to do with slowness while drilling down directories, not just at instantiation time. Something else is clearly going wrong, JFileChooser shouldn't be accessing unrelated drives when you drill down directories.

Gili

cowwoc
Offline
Joined: 2003-08-24

The "slowness on startup" bug is filed here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6372808

Please vote for it if you find this important. I tend to agree though, that JFileChooser should probably be rewritten from the ground up. At first glance, the implementation looks like a mess.

matthew_sleeman
Offline
Joined: 2006-07-25

5) swing always will be slower, it's drawing stuff itself.
it slower then AWT (which uses OS native methods) and slower then native programs, that's the price you pay for portablity

cowwoc
Offline
Joined: 2003-08-24

My gut feeling is that this isn't a Swing thing. You will note that if you navigate into a directory with 1000 files it opens *much* slower than a directory with 100 files. The bottleneck seems to be with the algorithm that scans the directory, not with the Swing code that paints the screen.

Someone who is familiar with the code should just run a profiler against it and take out and solve this mystery :)

Gili

swpalmer
Offline
Joined: 2003-06-10

It get's worse...

The details view also labels the file type column as "Modified" instead of "Type" and the modified date/time column ("Date Modified") is missing entirely!

... until you nativgate away from the folder that is, then the Size column is sorted correctly, the Type column gets the proper header, and the date modified column appears with the full "Date Modified" heading. Of course all the other columns that might normally appear in a native dialog are still missing.

loneid
Offline
Joined: 2006-04-13

Hi,

This is the known bug 6515169, and it's being fixed. I hope we will release the fix soon.

swpalmer
Offline
Joined: 2003-06-10

> Hi,
>
> This is the known bug 6515169, and it's being fixed.
> I hope we will release the fix soon.

The original bug #6384033 was reported a [b]year[/b] earlier... did the people at Sun think the screen shot was faked??? If not, more effort was needed in the investigation, since as you can see above the problem happens in a very simple and common test case.

I won't put all the blame on Sun though. Java 6 Update 1 would probably have this issue fixed if only the original report included a test case.

Please everyone, included a working test case in your bug reports whenever it's practical. It can make a big difference as we can see here.

loneid
Offline
Joined: 2006-04-13

Thanks for the code you posted! I added an extraction from it to the description of 6384033, and re-opened it.

> The original bug #6384033 was reported a [b]year[/b]
> earlier... did the people at Sun think the screen
> shot was faked???

Certainly not!

> If not, more effort was needed in
> the investigation, since as you can see above the
> problem happens in a very simple and common test
> case.

Probably it was. I requested more details from the bug initiator via email mentioned in the initial incindent ( http://webbugs.sfbay.sun.com/rt/incidentDisplay?incidentID=644047 ), and haven't got a reply for more than 2 months. That's why I decided that this issue was not reproducible anymore with newer builds, now I see that it was a mistake.

> Please everyone, included a working test case in your
> bug reports whenever it's practical. It can make a
> big difference as we can see here.

It would be great.

matthew_sleeman
Offline
Joined: 2006-07-25

1) This happens when you move the mouse off JFileChooser dialog or any other componet created by you java program, right? If so is something to do with Swing it self, not the JFileChooser, could be that your working under Windows, it doesn't like java much.

2) I Have noticied similiar behavoir with Explorer, it is native Windows behavoir. It's hard to replicate. Not sure really why it happens

cowwoc
Offline
Joined: 2003-08-24

1) I don't think this is the case for me. I invoke File | Open ... close the dialog ... then a few minutes later I invoke File | Open again and sometimes the focus problem arises. It seems somewhat random.

2) I noticed it happens more often under JFileChooser than the native explorer. I think it is a configurable double-click-sensitivity setting.

i30817
Offline
Joined: 2006-05-02

In a related issue if you want the filechooser not to ever enter edit mode for files or directories you can use the last "secret" swing property that i entered in this wiki of those properties.

http://wiki.java.net/bin/view/Javadesktop/SecretSwingProperties

This link should be better known... or the swing team should fix their components even at the cost of some incompatibilities.

kirillcool
Offline
Joined: 2004-11-17

Why not use the FileChooser?

cowwoc
Offline
Joined: 2003-08-24

It doesn't behave natively either. Last time I tried it I remember it had the Win2k skin while running under WinXP. I really wouldn't mind using FileChooser if it really behaved natively, though obviously I would prefer the added flexibility of JFileChooser.

I'll try FileChooser later on today to see whether it has improved in Java6 final.

Artem Ananiev

The last change to FileDialog (=FileChooser?) is in 7.0, check the
latest 7.0 build. It looks like Win2K dialog on Win2K, like WinXP dialog
on WinXP and *almost* like Vista dialog on Vista.

Artem

swing@javadesktop.org wrote:

> It doesn't behave natively either. Last time I tried it I remember it had the Win2k skin while running under WinXP. I really wouldn't mind using FileChooser if it really behaved natively, though obviously I would prefer the added flexibility of JFileChooser.
>
> I'll try FileChooser later on today to see whether it has improved in Java6 final.
> [Message sent by forum member 'cowwoc' (cowwoc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=210317

loneid
Offline
Joined: 2006-04-13

> The last change to FileDialog (=FileChooser?) is in

I guess the talk is about JFileChooser.

In JDK 7.0, we plan to add support for native file dialog in Swing, as well as we will continue improving the existing JFileChooser, as we know it is not good enough so far.

I would like to ask you developers, to vote for the CR's important for you at http://bugs.sun.com/bugdatabase/ , it will help us to fix them in the right order.

Thanks for your interest!

Leonid Popov
Swing team engineer

swpalmer
Offline
Joined: 2003-06-10

> I would like to ask you developers, to vote for the
> CR's important for you at
> http://bugs.sun.com/bugdatabase/ , it will help us to
> fix them in the right order.
>
> Thanks for your interest!
>
> Leonid Popov
> Swing team engineer

Then please put some effort into things before closing obvious bugs like http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384033

The sorting on the size column is broken (sorting is alphabetic not numeric) and it makes my application look stupid. When I check I see that it has already been reported and somehow the person that reviewed it was unable to reproduce it. Look at the comments on the bug report... it is a real bug.

loneid
Offline
Joined: 2006-04-13

Hi,

Thanks for the notification. It was almost impossible to guess what were the conditions causing this bug to appear, because its description said only "Open a JFileChooser, selected detailed view, sort on Size column." This (and not only this) scenario was tested many times by both engineers and testers and the issue was not reproducible. May I ask you to send me a code snippet and/or step-by-step instructions leading to the issue?

swpalmer
Offline
Joined: 2003-06-10

Run this on windows... (from a folder other than C:\)
Choose the detailed view. It will exhibit the problems noted above every time.
If you don't have much in the root of C: to see the size sorting problem, try changing the path in the code to "C:\\Windows"

[code]
/*
* Demonstrates bugs in the details view of JFileChooser on Java 6
*/

package jfilechooserdetails;

import java.io.File;
import javax.swing.JFileChooser;

public class Main {

public static void main(String[] args) {
JFileChooser fc = new JFileChooser(new File("C:\\"));
fc.showOpenDialog(null);
}

}

[/code]

Message was edited by: swpalmer

swpalmer
Offline
Joined: 2003-06-10

This can also be reproduced with:

[code]
public static void main(String[] args) {
File startDir = new File("C:\\Windows");
JFileChooser fc = new JFileChooser();
fc.setCurrentDirectory(startDir);
fc.showOpenDialog(null);
}

[/code]

The code isn't unusual, so you can imagine why it is disappointing that neither of these scenarios were tested when the bug was first reported. Though I admit the person that reported the bug initially should have provided the code for a test case given that it is so trivial. But given that a screen shot was provided in the bug report, surely that should have convinced someone that there was something to it.

qu0ll
Offline
Joined: 2006-12-09

Not only that, but if you configure Windows to use single-click for file selection then this is not evident in the Swing file chooser - a dead giveaway that you are using a non-native control when you are used to everything being single-click.

--
And loving it,

-Q
______________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email)