Skip to main content

Are the updates to FileDialog coming in Java 7?

9 replies [Last post]
Joined: 2003-06-18

I would like to know if FileDialog is planned to be fixed in Java 7 to contain all the features of the native FileDialog. I couln't find anything in the release notes of Java 7. I've talked about this over and over but no one seems to answer.
Can anyone from the AWT/Swing team give us a status please?
Guys if you're interested in improving FileDialog vote for this bug:

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-10

What about improvements to the Swing JFileDialog?

To what degree will we be able to customize the native file dialogs? (e.g. file filters, button text, etc.)

Will we be able to add an accessory component? (This appears to be possible on Windows with native dialogs, so I hope it will be available.)

Is it possible to use the native implementation just of the file list area (to get all the context menu goodies and icon decorations), but keep the Swing controls for the main dialog? I figured with the improved heavyweight/lightweight support in Java 7 this might actually make sense to try.

As you might expect - I need (or at least very much want) the features of JFileChooser. So while I recognise the need for the fidelity of the native file chooser - I can't loose the features with respect to what is available in the Swing version like I must with the current implementations.

Joined: 2007-12-22

IMHO, under Windows, perhaps so far the only practical workaround is to call CFileDialog directly with JNI.

It's much faster than JFileChooser and supports image preview. I wrote a wrapper class of CFileDialog, if you are interested, you can get the source from google code.


Joined: 2006-05-02

For linux there is this:

Much slower, but less jarring.

Anyway. I found a bug in the files given by the jfilechooser you should be aware of when serializing in a shutdown hook.

They are a special extension that needs a executor to access some serialization properties (it is closed when awt dies) so it's possible that trying to serialize in the S.H. it throws a exception. Its easily avoided by using the string path instead (seems to be eager). I reported, but as the filechooser is going to change, and it is unusual, they apparently did nothing i think.

Joined: 2006-08-03

Yes, there are plans to add improved support for native file dialogs in JDK7.


Joined: 2003-06-18

Thanks Dmitry. Do you have any idea when this will be included?


Joined: 2007-04-29

> Can anyone from the AWT/Swing team give us a status
> please?
> Guys if you're interested in improving FileDialog
> vote for this bug:
this should have IMO higher priority to fix:
there are still serious performance problems with file dialogs (thats why there is a custom implementation in NetBeans 6)

I also like to point out that the JComboBox button is not rendered on Linux GTK window manager (->ubuntu's default)

there are also compiz/beryl/compiz-fusion related problems on ubuntu
but I am sure most linux user in this forum know that already ;)

how to attack Flash If we even can't use the default Filechooser on windows, can't open a frame on Ubuntu with GL Desktop enabled or require workarounds for system tray icons?

I hope there will be enough time left to fix some of the desktop integration issues for the consumer release, Java 7 haven't even been announced yet....

Joined: 2003-06-18

JFileChooser is not the answer. Native FileDialog should be fixed as Java should use the best that each platform provides not to reinvent the wheel.
JFileChooser is slow, doesn't support thumbnails and doing so in Java without caching is a joke, it would just be too slow and since no one wants to have something like thumbs.db to clutter his machine the best solution remains to fix FileDialog.
Java 7 was supposed to bring these changes.
This is crucial for the future of Java as a viable rich client platorm.
I develop Swing applications but believe me I love everything that looks native and believe it or not native controls are more tested and have fewer bugs than complex components such as JFileChooser.

Carl Antaki

Joined: 2006-07-26

I concur. It often doesn't take more than a few secs to assert that you are using a Swing app, Every single time I want to open a file in NetBeans, I'm annoyed at it's constant desire to want to rename files.

Joined: 2003-08-24

I don't even think we need to wait for Java7 for some of this stuff. I've personally been requesting that FileChooser should look and feel exactly like a native file chooser in Windows for years now. There shouldn't even be a need to wait until Java7 to do this because it isn't a feature request, it is purely a bug fix. Obviously I'd like JFileChooser to also look and feel identical to the native controls under the Windows L&F but if you deliver a FileChooser solution then obviously this becomes lower priority.

I too would like to know when the AWT/Swing team plan on delivering this update.

I agree with carcour that Sun needs to resolve what it wants to do with FileChooser and JFileChooser moving forward, whether it wishes to implement the same functionality twice or whether there is an easier way to do this.

Thank you,