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.
JFileChooser takes much time to instantiate and to browse large folders. In comparison with 6u1, performance degraded significantly.
The issue was initially reported at http://www.javalobby.org/forums/thread.jspa?messageID=92159440
This bug is a cause of fix of CR 6491795. Closed as "Not reproducible" because the fix of CR 6491795 for jdk7 contains fix of this CR as well.
For the SDN community
Please note that this CR doesn't address the ZIP issue, it rather concerns overall performance degradation after the COM fix (see CR #6491795). For the ZIP issue, there's a special CR #5050516. You can find links to the both mentioned CR's in the 'Related CRs' section on this page.
I profiled it and found 3 major bottlenecks:
a) frequent calls to Win32ShellFolder2.isFileSystem() and Win32ShellFolder2.isLink(). The both methods invoke hasAttribute() that in turn delegates execution to the COM thread.
b) frequent calls from BasicDirectoryModel.LoadFilesThread to various Win32ShellFolder2's methods delegating execution to the COM thread.
c) frequent calls from FilePane.DetailsTableRowSorter to Win32ShellFolder2.ColumnComparator.compare() on file sorting, also delegating execution to the COM thread.