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
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]
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.
which is a dup of a still open:
Vladimir, add notes about your setup specifics directly to the JDK issue, raising its priority eventually. Thanks.