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.
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.
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.
Reassigning to openide for evaluation.
Tim, is still this bug relevant? There is new directory FileChooser in NetBeans 6.0.
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); chooser.doLayout(); } 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...
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 reusal,... (And one for me, contrib/jabber's remote control patch would be smaller and more maintainable)
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.
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 me...how 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...
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.
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.
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 closing.