JDK-8022057 : JFileChooser blocks EDT in Win32ShellFolder2.getIcon
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 7u15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2013-08-01
  • Updated: 2023-01-14
  • Resolved: 2015-06-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b72Fixed
Related Reports
Relates :  
JDK-8300173 - Handle E_PENDING result for IExtractIconW::GetIconLocation
Description
JFileChooser on windows calls:

com.sun.java.swing.plaf.windows.WindowsFileChooserUI$WindowsFileView.getIcon()

which may get into

sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke()

and block on 

java.util.concurrent.FutureTask.get()

https://netbeans.org/bugzilla/show_bug.cgi?id=188001
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5f13327d5192 User: lana Date: 2015-07-08 22:17:44 +0000
08-07-2015
URL: http://hg.openjdk.java.net/jdk9/client/jdk/rev/5f13327d5192 User: ssadetsky Date: 2015-06-16 05:47:39 +0000
16-06-2015
As for JFileChooser spontaneous delays: I could not reproduce this under Win7 and jdk8/9. But I found in MSDN that ExtractIcon Win32 API call can take significant amount of time in some cases. Mostly when the file is an executable or a link and its icon is not cached yet. MS propose a way how to avoid that: use asynchronous flag GIL_ASYNC with GetIconLocation call which then will return E_PENDING which means consequent ExtractIcon call can take time. There are several ways to handle E_PENDING return I propose just to use the default icon for the file which can be obtained with GIL_DEFAULTICON flag and should be much faster. Since I cannot reproduce the issue I don't know how effective it will be. Also I will add possibility to get Windows-Libraries icons, which were not available before in the FileChooser.
27-05-2015
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014
Release team: Approved for deferral.
22-10-2013
I think we should create a wrapper that can draw something while the image is loading. It is not a simple change in the current implementation.
22-10-2013
One of the authors said that additional thread to load images was added for Windows Vista, because we must initialize and use COM on the same thread to avoid different problems. There is a very complex synchronization between this thread and EDT. So even if we slow down the getIcon method and reproduce the issue, we cannot easily fix it. It is too risky.
22-10-2013
NetBeans appear to have at least 3 dups of this one, which suggests that their users are running into it. Given Yuri's comment that it is easy to reproduce then it seems prudent to do at least some investigation and understand the impact and likelihood.
18-10-2013
As I understand -- correct me if I'm wrong -- it is rather easy to reproduce on NetBeans 6* or indeed hacking WindowsFileView.getIcon() with a delay -- but I'm afraid it's would be hard to fix in 8 having in mind current workload and time scarcity. jdk8: SQE OK to defer
16-10-2013