JDK-8265446 : JFileChooser slow with network shortcut on desktop
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 8,11
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows
  • CPU: x86_64
  • Submitted: 2021-04-12
  • Updated: 2022-02-08
  • Resolved: 2022-02-08
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
A DESCRIPTION OF THE PROBLEM :
When you have a shortcut file (*.lnk) on the desktop that points to a location on a network server to which you must authenticate, the JFileChooser is very slow to open and change folders. This occurs in the same case as JDK-8213583 when you have a security manager set. Without a security manager set, changing directories is fast except when changing to the desktop.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a shortcut file on your desktop to a network server to which you need to authenticate. You'll know you have this setup correctly if you double click the shortcut and see a "Windows Security" dialog asking you to "Enter your credentials to connect to: <SERVERNAME>"
2. Run the test case file with Java 11 or later

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The file chooser opens quickly and changing directories is fast.
ACTUAL -
The file chooser takes a while to open and changing directories is very slow.

---------- BEGIN SOURCE ----------
import java.io.*;
import javax.swing.JFileChooser;

/////////////////////////////////////
//
// NOTE:
// There must be a shortcut on the Windows desktop referencing a network location
// that requires authentication before running this program.
//
public class SlowLinkBug {
    public static void main(String[] args) throws Exception {

        // Creates a temporary security policy
        final File tempPolicyFile = File.createTempFile("broken-links-bug-", ".policy");
        tempPolicyFile.deleteOnExit();
        try (final PrintStream policyStream = new PrintStream(new FileOutputStream(tempPolicyFile))) {
            policyStream.println("grant { permission java.security.AllPermission; };");
        }
        System.setProperty("java.security.policy", tempPolicyFile.getAbsolutePath());

        // Trigger the problem
        System.setSecurityManager(new SecurityManager());
        JFileChooser chooser = new JFileChooser();

        chooser.showDialog(null, "Open"); // not really needed
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Remove the link from the desktop or don't set a security manager.

FREQUENCY : always



Comments
According to the comment above the issue was fixed in JDK 17 and above by JDK-8266459 Implement JEP 411: Deprecate the Security Manager for Removal. Currently there are no plans to back-port that changes to JDK 8u and JDK 11u. I am closing this one as "Won't Fix", please re-open if you feel I missed anything.
08-02-2022

I am not able to reproduce the issue in jdk17 and later and also It does not seem to be applicable to jdk17and later as I am getting #./jdk/bin/java SlowLinkBug Exception in thread "main" java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release at java.base/java.lang.System.setSecurityManager(System.java:411) at SlowLinkBug.main(SlowLinkBug.java:22) This is because of JDK-8266459 Implement JEP 411: Deprecate the Security Manager for Removal done in recent jdk17 where Security Manager is deprecated and is earmarked for removal in subsequent release and since this issue is seen to be not reproducible without Security Manager, it is not much of concern in mainline so I am changing fix version to 11-pool and below as the above Security Manager removal enhancement is not yet backported to 11u and earlier trains.
12-11-2021

Removing the credential to network location, rechecked with the issue, observed slowness while opening JFilechooser C:\> net use * /delete Test Result: ========= 8: Fail 8u291: Fail 11: Fail 11.0.11: Fail 16: Fail 17ea: Fail
31-05-2021

Additional information from submitter: =========================== JDK-8265446 was closed as cannot reproduce, but it is easily reproducible if you have a link that takes a while to resolve. In my case, when I right click the link file in the Windows explorer, it takes a while (~5 seconds) before displaying the context menu. Debugging the SlowLinkBug.java shows that is spends a similar amount of time in the native method `sun.awt.shell.Win32ShellFolder2.getLinkLocation(long, long, boolean)`. This is ultimately called from the callable within `Win32ShellFolder2.getLinkLocation(boolean)`: Win32ShellFolder2.getLinkLocation(boolean) line: 869 Win32ShellFolder2.getLinkLocation() line: 865 Win32ShellFolderManager2.checkFile(File, SecurityManager) line: 431 Win32ShellFolderManager2.lambda$checkFiles$0(SecurityManager, File) line: 459 1444635922.test(Object) line: not available ReferencePipeline$2$1.accept(P_OUT) line: 176 Spliterators$ArraySpliterator<T>.forEachRemaining(Consumer<? super T>) line: 948 ReferencePipeline$2(AbstractPipeline<E_IN,E_OUT,S>).copyInto(Sink<P_IN>, Spliterator<P_IN>) line: 484 ReferencePipeline$2(AbstractPipeline<E_IN,E_OUT,S>).wrapAndCopyInto(S, Spliterator<P_IN>) line: 474 ReferencePipeline$2(AbstractPipeline<E_IN,E_OUT,S>).evaluate(Spliterator<P_IN>, boolean, IntFunction<E_OUT[]>) line: 550 ReferencePipeline$2(AbstractPipeline<E_IN,E_OUT,S>).evaluateToArrayNode(IntFunction<E_OUT[]>) line: 260 ReferencePipeline$2(ReferencePipeline<P_IN,P_OUT>).toArray(IntFunction<A[]>) line: 517 Win32ShellFolderManager2.checkFiles(Stream<File>, SecurityManager) line: 460 Win32ShellFolderManager2.checkFiles(File[]) line: 447 Win32ShellFolder2.listFiles(boolean) line: 795 Win32ShellFolder2(ShellFolder).listFiles() line: 124 Win32ShellFolderManager2.get(String) line: 312 ShellFolder.get(String) line: 259 MetalFileChooserUI$DirectoryComboBoxModel.addItem(File) line: 1029 MetalFileChooserUI.doDirectoryChanged(PropertyChangeEvent) line: 717 MetalFileChooserUI$5.propertyChange(PropertyChangeEvent) line: 806 PropertyChangeSupport.fire(PropertyChangeListener[], PropertyChangeEvent) line: 341 PropertyChangeSupport.firePropertyChange(PropertyChangeEvent) line: 333 PropertyChangeSupport.firePropertyChange(String, Object, Object) line: 266 JFileChooser(Component).firePropertyChange(String, Object, Object) line: 8731 JFileChooser.setCurrentDirectory(File) line: 595 JFileChooser.<init>(File, FileSystemView) line: 349 JFileChooser.<init>() line: 295 SlowLinkBug.main(String[]) line: 23 (Line numbers are based on JDK 11.0.9) `sun.awt.shell.Win32ShellFolderManager2.checkFiles(File[])` returns immediately if there is no security manager set which is why it works quickly in that case. For some reason, the files on the desktop are always included (see `sun.awt.shell.Win32ShellFolderManager2.get(String)` line 312: `checkFiles(desktop.listFiles())`. It's not clear why all the files in the desktop folder need to be included in the file check unless you are browsing the desktop folder itself. Even then it seems strange to check the target of all the links.
20-04-2021

Checked with attached Testcase in Windows 10, Issue could not be reproduced, Followed steps as mentioned in the description, was able to access/change directories, didn't observe slowness in accessing/changing directories. Test Result: ========= 8u281: Pass 11.0.10: Pass 16: Pass 17ea: Pass
19-04-2021