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.
In every "Browse..." button or every time a JFileChooser that NetBeans open, it takes too much time to open, and then for every folder selected takes too much time to refresh view.
See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6317789 "..the bug is not present if you set the "useShellFolder" property to false..." Perhaps NetBeans can provide a way for the user to set this property, which may be useful for those users who find the UI too slow. Also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6372808
This issue was originally reported on the nbusers forum at: http://www.netbeans.org/servlets/BrowseList?list=nbusers&by=thread&from=799682 The forum thread was updated as follows: After removing 3 zip files on my desktop, the performance issue with JFileChooser is gone! It seems to be a issue on jre and not on netbeans…. It looks like the problem seems to be with accessing folders on the Windows desktop itself (in fact the chooser is known to hang when a shortcut to desktop is on the desktop, leading possibly to infinite loop..) Perhaps NetBeans can consider working around this problem by exlcuding windows desktop itself...not sure if that is advisable or feasible...
Lowering to P2, please don't abuse priority or it will not work at all... However providing command line switch to disable shellFolder seems reasonable, as this report is repeated, users find this slowness to be a problem...
> this report is repeated yes, see also http://www.javalobby.org/java/forums/t98389.html?start=0#92159232 Dafe, try to implement what you suggested yesterday when we discussed this. Measure the time it takes to initialize shellFolder and if it is too long, show the user a hint that she may have many/large files on Desktop.
FWIW, there is a cheap trick to make file choosers open very fast, which I use in standalone applications. It only works if you cache and reuse one JFileChooser, and you are really moving the work to startup, but it does work: static JFileChooser chooser = new JFileChooser(); static { CellRendererPane pane = new CellRendererPane(); pane.add (chooser); chooser.doLayout(); } Probably for a lot of cases we could just reuse a single filechooser. Maybe something to add to the Dialogs API?
*** Issue 110525 has been marked as a duplicate of this issue. ***
*** Issue 110625 has been marked as a duplicate of this issue. ***
*** Issue 113203 has been marked as a duplicate of this issue. ***
*** Issue 113587 has been marked as a duplicate of this issue. ***
*** Issue 113581 has been marked as a duplicate of this issue. ***
*** Issue 116805 has been marked as a duplicate of this issue. ***
*** Issue 116812 has been marked as a duplicate of this issue. ***
Integrated bug workaround, based on Tim's suggestion. It solves problem of first slow start of JFileChooser (see JDK bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516), but I think there will still be problems of slow browsing, mentioned in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578753 and related. Sadly nothing we can do with it. /cvs/core/swing/dirchooser/manifest.mf,v <-- manifest.mf new revision: 1.3; previous revision: 1.2 done RCS file: /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/resources/layer.xml,v done Checking in src/org/netbeans/swing/dirchooser/resources/layer.xml; /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/resources/layer.xml,v <-- layer.xml initial revision: 1.1 done RCS file: /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java,v done Checking in src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java; /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java,v <-- JFileChooserWarmUpTask.java initial revision: 1.1
*** Issue 104255 has been marked as a duplicate of this issue. ***
*** Issue 106420 has been marked as a duplicate of this issue. ***
*** Issue 119711 has been marked as a duplicate of this issue. ***
Reopening. The fix does not work for me. With Beta 2 I have two twenty meg zip files on desktop of my Win XP machine and opening the Open Project directory chooser takes 1:35 min. Before invoking the action I left the IDE running for five minutes, so the warmup workaround should have finished, but it obviously did not work. Now I tried patching DelegatingChooserUI with fc.putClientProperty("FileChooser.useShellFolder", Boolean.FALSE); as suggested in the JDK bug and this really helped. I believe the only safe way for 6.0 is now patching it this way. The users will miss the quick navigation sidebar, but I do not know about a better fix. The issues against JDK were escalated and they should be fixed for 6u4, so we can reconsider the navigation sidebar for next NetBeans release after we verify the problem is fixed with 6u4. For reference: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6372808 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578753
I tried really hard and spent some time on this and workaround worked well for me... Anyway, I've given up: Removing src/org/netbeans/swing/dirchooser/resources/layer.xml; /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/resources/layer.xml,v <-- layer.xml new revision: delete; previous revision: 1.1 done Checking in src/org/netbeans/swing/dirchooser/DelegatingChooserUI.java; /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/DelegatingChooserUI.java,v <-- DelegatingChooserUI.java new revision: 1.4; previous revision: 1.3 done Removing src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java; /cvs/core/swing/dirchooser/src/org/netbeans/swing/dirchooser/JFileChooserWarmUpTask.java,v <-- JFileChooserWarmUpTask.java new revision: delete; previous revision: 1.1 done Checking in manifest.mf; /cvs/core/swing/dirchooser/manifest.mf,v <-- manifest.mf new revision: 1.4; previous revision: 1.3
*** Issue 119774 has been marked as a duplicate of this issue. ***
*** Issue 120078 has been marked as a duplicate of this issue. ***
*** Issue 120287 has been marked as a duplicate of this issue. ***
*** Issue 113808 has been marked as a duplicate of this issue. ***
*** Issue 115792 has been marked as a duplicate of this issue. ***
*** Issue 121648 has been marked as a duplicate of this issue. ***
*** Issue 121631 has been marked as a duplicate of this issue. ***
*** Issue 121762 has been marked as a duplicate of this issue. ***
*** Issue 123180 has been marked as a duplicate of this issue. ***
> ------- Additional comments from anebuzelsky Wed Oct 24 11:59:52 +0000 2007 ------- > The issues against JDK were escalated and they should be fixed for 6u4, so we can reconsider the navigation sidebar for > next NetBeans release after we verify the problem is fixed with 6u4. Should this bug be reopened for 6.1 so that this issue is tracked correctly for the next version?
> Should this bug be reopened for 6.1? No. A separate issue should be filed, an enhancement to reenable the quick navigation sidebar after the JDK bug is fixed in an update of JDK6. BTW, at this moment we know the bug is fixed in 6u10, and not fixed in 6u4.
*** Issue 126329 has been marked as a duplicate of this issue. ***
*** Issue 118861 has been marked as a duplicate of this issue. ***
*** Issue 144898 has been marked as a duplicate of this issue. ***
*** Issue 154189 has been marked as a duplicate of this issue. ***
*** Issue 157904 has been marked as a duplicate of this issue. ***
I use NetBeans PHP 6.7 version. Have been testing (and using when *possible) since it was 5.5. File browser performance is very poor since then. I don't understand why you guys are not interested to resolve this annoying issue. I'm not sure, but seems the file browser also walks into least directory of each current directory (when I click on the + sign or double click the folder). Also, if I try to open 4/5 files at a time by (ctrl + click on files) it is noticeably much slow. (*because it's really quite slow than other IDE's) Keep up the good work. Good Luck !
Please self profile your IDE as described at http://wiki.netbeans.org/FitnessViaPartnership and provide us more information about the slowness you are observing. Thanks.
*** Bug 181170 has been marked as a duplicate of this bug. ***
v/c