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.
This issue was reported manually by vv159170. It already has 4 duplicates Build: NetBeans IDE Dev (Build 20130124-94e02e22bb69) VM: Java HotSpot(TM) Server VM, 23.6-b04, Java(TM) SE Runtime Environment, 1.7.0_10-b18 OS: SunOS User Comments: rptmaestro: Right-clicked in favorites to open file chooser for adding a folder. vv159170: add foler to favorites Maximum slowness yet reported was 7770 ms, average is 5337
Created attachment 130570 [details] nps snapshot
slowness in a standard Java JFileChooser: > javax.swing.AbstractButton.doClick(): 7630 / 0 > javax.swing.DefaultButtonModel.setPressed(): 7630 / 0 > javax.swing.DefaultButtonModel.fireActionPerformed(): 7630 / 0 > javax.swing.AbstractButton$Handler.actionPerformed(): 7630 / 0 > javax.swing.AbstractButton.fireActionPerformed(): 7630 / 0 > javax.swing.plaf.basic.BasicFileChooserUI$ApproveSelectionAction.actionPerformed(): 7630 / 0 > java.io.File.exists(): 2850 / 0
Ondra, let's leave it open and discuss it while I'm in Prague. It's the problem our customers face in Studio IDE product. We should find a solution
sure, there is a solution, JDK team could probably fix it and optimize the default implementation.
What do you use in cnd code for file browsing and selecting to avoid BasicFileChooserUI.ApproveSelectionAction.actionPerformed and multiple calls to file.exists, file.isDirectory and others there? Maybe i can reuse the same implementation.
Ondrej. Not sure we have solved all the issues on cnd side, but our file chooser impl for remote file system can be found in package org.netbeans.modules.remote.api.ui in dlight.remote module FileChooserBuilder & RemoteFileSystemView does some tricks to have "Loading" instead of UI freezes when i.e. dbl-click to jump into nested folder from current files list
problem of all standard file choosers throughout the IDE, should be solved not only in Favorites but a general solution should be found.
there are five invocations of java.io.UnixFileSystem.getBooleanAttributes() which take 1,919 ms, 1,419 ms, 2850 ms, 720 ms and 719 ms respectively. It seems that the filesystem has to be really slow for basic operation to take that long. Nonetheless if something can be done about this it should probably be done by jdk team. Reassigning to platform/jdk to evaluate, whether this is important enough to report to jdk...
There are very old issues filed against JFileChooser about this. E.g. https://bugs.openjdk.java.net/browse/JDK-4401639 which is a dup of a still open: https://bugs.openjdk.java.net/browse/JDK-4260746 Vladimir, add notes about your setup specifics directly to the JDK issue, raising its priority eventually. Thanks.
*** Bug 246276 has been marked as a duplicate of this bug. ***