-2

We are experiencing slowness in our Java swing application. By observing stack traces at the time of GUI slowness, AWT Thread is in waiting state. To be specific below is the stacktrace observed multiple times.

"AWT-EventQueue-2" prio=0 tid=30 nid=0 waiting on condition [on lock java.util.concurrent.FutureTask@3312ed4c]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.util.concurrent.FutureTask.awaitDone(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown Source)
at sun.awt.shell.ShellFolder.invoke(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.listFiles(Unknown Source)
at sun.awt.shell.ShellFolder.listFiles(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2.get(Unknown Source)
at sun.awt.shell.ShellFolder.get(Unknown Source)
at javax.swing.plaf.metal.MetalFileChooserUI$DirectoryComboBoxModel.addItem(Unknown Source)
at javax.swing.plaf.metal.MetalFileChooserUI$DirectoryComboBoxModel.access$800(Unknown Source)
at javax.swing.plaf.metal.MetalFileChooserUI.doDirectoryChanged(Unknown Source)
at javax.swing.plaf.metal.MetalFileChooserUI.access$1100(Unknown Source)
at javax.swing.plaf.metal.MetalFileChooserUI$5.propertyChange(Unknown Source)
at java.beans.PropertyChangeSupport.fire(Unknown Source)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at java.awt.Component.firePropertyChange(Unknown Source)
at javax.swing.JFileChooser.setCurrentDirectory(Unknown Source)
at javax.swing.JFileChooser.<init>(Unknown Source)
at javax.swing.JFileChooser.<init>(Unknown Source)
.
.
.
.
at javax.swing.SwingWorker$5.run(Unknown Source)
at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(Unknown Source)
at sun.swing.AccumulativeRunnable.run(Unknown Source)
at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(Unknown Source)
at javax.swing.Timer.fireActionPerformed(Unknown Source)
at javax.swing.Timer$DoPostEvent.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

Locked synchronizers: count = 0

Java version : 1.8.0_121

Is this a of bug in Java ? Has anyone faced similar issue?

Could anyone please help.

Thanks in advance!

Vamsi
  • 9
  • 4
  • Yes, `JFileChooser` is slow to initialise the first time. I tend to create a single instance (for what ever situation I'm using for) and re-use it where possible, it's not always possible, but from experience, it's typically only occurs when you create the first instance of `JFileChooser`. If you experience every time you create an instance of `JFileChooser`, try and cache that instance – MadProgrammer Dec 01 '17 at 22:53
  • Restart [`ColorChooserDemo2`](https://docs.oracle.com/javase/tutorial/uiswing/examples/components/ColorChooserDemo2Project/src/components/ColorChooserDemo2.java) to see the effect. – trashgod Dec 01 '17 at 23:16

1 Answers1

0

I think we have hit exactly same the issue mentioned at JFileChooser with disconnected network drives

Removed the disconnected network drive and the performance is imporved.

Vamsi
  • 9
  • 4