This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 82427

Summary: API for creating JFileChoosers (and having only one JFileChooser instance)
Product: platform Reporter: _ tboudreau <tboudreau>
Component: Window SystemAssignee: issues@platform <issues>
Status: NEW ---    
Severity: blocker CC: pzajac
Priority: P3 Keywords: API
Version: 5.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 47737    
Bug Blocks:    

Description _ tboudreau 2006-08-10 23:34:22 UTC
Almost every menu item or button that opens a file chooser dialog takes longer
to show the dialog than the recommended responsiveness time, at least on Windows.

The culprit here is the time it takes simply to construct a JFileChooser and
assemble its UI.

A simple fix for this would be to keep one non-disposed JFileChooser and reuse
it as needed - there are no cases where two JFileChoosers are open at once. 
This could easily be done as part of the fix for issue 82425;  or, there is a
Utilities.createJFileChooser() method, due to an old JDK bug workaround.  That
could be reused, but it would make more sense to solve issue 82425 at the same time.
Comment 1 Marian Petras 2006-08-21 17:06:28 UTC
The Utilities module is only one of many modules displaying file choosers - and
by far its Open File action is not the most frequently used one. Reassigned to
(pseudo)module 'ide' because once the API requested in issue #82425 is
established, it should be used by various modules across the IDE.
Comment 2 novakm 2007-07-26 16:14:27 UTC
Reassigning to openide for evaluation.
Comment 3 pzajac 2007-07-26 16:41:18 UTC
Tim, is still this bug relevant? There is new directory FileChooser in NetBeans 6.0.
Comment 4 _ tboudreau 2007-07-26 19:13:18 UTC
I think it is still relevant.  The performance on Windows in particular is not great.

As I mentioned in another issue, there is a trick that works (if you don't mind moving the work to startup), to make file choosers very fast:

static JFileChooser chooser = new JFileChooser();
static {
   CellRendererPane pane = new CellRendererPane();
   pane.add (chooser);

After that, the filechooser will be extremely fast.

There is another problem we could solve here:  Many different parts of NetBeans display file choosers.  Most of them create their own and they open 
against the user's home dir (no matter what they selected the previous time).

It would be much nicer to have a utility method, i.e. Utilities.createFileChooser (stringToken, params...), which would ideally reuse an existing filechooser so 
it is fast, and automatically find the last-used directory for that token in NbPreferences.  We could kill two birds with one stone...
Comment 5 Petr Nejedly 2007-07-27 13:23:36 UTC
Note that there currently is (deprecated) Utilities.showFileChooser, which might work for many use cases.
I would suggest to gather the use cases (some modules need some additional fancy over plain file chooser) and find an
API that would cover them to such an extent so we can gather the benefits - one place to keep last folder, fast instance
(And one for me, contrib/jabber's remote control patch would be smaller and more maintainable)
Comment 6 _ tboudreau 2007-07-27 14:04:39 UTC
Well, the main thing is undoing whatever was done to the filechooser in its last use - i.e. override add*Listenr and keep a copy of the listeners and remove 
them after use, and also intercept things like setting the decorator component.  Shouldn't be hard, it's just bookkeeping and grunt-code to monitor and undo 
on disposal.  Somewhere I have a patch I wrote in 2002 that does this for JDialogs for DialogDisplayer, which could probably be reused with some 
JFileChooser-specific additions.
Comment 7 David Simonek 2007-09-10 16:19:30 UTC
I'm not feeling comfortable with proposed solution - as far as I understand, it's moving the delay to the startup and
originally its JDK bug. Undoing property sets seems risky to can I be sure that I bring JFileChooser to the
very same state as after complete init? What to do when JDK guys will add state representation data? I would rather wait
for JDK fix here...
Comment 8 _ tboudreau 2007-09-11 06:21:24 UTC
I don't love it either, but though it moves the work to startup, it also only ever has to happen once.  Or it could be done the first time a JFileChooser is created.

If the JDK team ever dramatically improves time to create JFileChoosers, we can always get rid of the reusable one and have the code create a new one.  The 
resource cost of one JFileChooser hanging around in memory shouldn't be too high.  And it solves the directory problem at the same time.
Comment 9 _ tboudreau 2007-09-11 06:23:47 UTC
Re being the same state as a complete init, that should work okay.  I prototyped it years ago with reusing dialogs in DialogDisplayer, and it worked nicely.  As 
long as we override/wrap every setter and listener adding method, it should work.  I could imagine a problem if JFileChooser had new methods added to it, 
but that would be a JDK bug and easily caught before a new JDK was released.
Comment 10 David Simonek 2007-10-04 14:05:08 UTC
OK, I fixed slowness problem on Windows by implementing Tim's suggestion into warm up task. Now it behaves a good enough
from performance point of view.

However, other issues for having single JFileChooser persists, so I'm turning this into proper enhancement instead of