JDK-6789085 : Applet Deadlock During Initialization
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-12-25
  • Updated: 2011-01-26
  • Resolved: 2009-02-06
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 6
6u14 b01Fixed
Description
FULL PRODUCT VERSION :
all Java 1.6.x versions

ADDITIONAL OS VERSION INFORMATION :
Windows XP and Windows Vista

A DESCRIPTION OF THE PROBLEM :
We observe an occasional deadlock during applet initialization. Using JConsole, we see that the AWT-EventQueue-0 thread is deadlocked with the applet initialization thread. The stack trace shows the deadlock occurs before our applet code. It's during the construction of the JApplet. Here's the stack trace of both threads:

Name: Thread-39
State: BLOCKED on sun.awt.windows.WDesktopProperties@2a3135 owned by:
AWT-EventQueue-0
  Total blocked: 1  Total waited: 0

Stack trace:
sun.awt.windows.WDesktopProperties.removePropertyChangeListener(Unknown Source)
sun.awt.windows.WToolkit.removePropertyChangeListener(Unknown Source)
   - locked sun.awt.windows.WToolkit@19616c7
javax.swing.plaf.metal.MetalLookAndFeel$AATextListener.dispose(Unknown Source)
javax.swing.plaf.metal.MetalLookAndFeel.flushUnreferenced(Unknown Source)
javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(Unknown Source)
javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(Unknown Source)
javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(Unknown Source)
javax.swing.UIManager.setLookAndFeel(Unknown Source)
javax.swing.UIManager.setLookAndFeel(Unknown Source)
javax.swing.UIManager.initializeDefaultLAF(Unknown Source)
javax.swing.UIManager.initialize(Unknown Source)
javax.swing.UIManager.maybeInitialize(Unknown Source)
   - locked java.lang.Object@1c8c58
javax.swing.UIManager.getUI(Unknown Source)
javax.swing.JPanel.updateUI(Unknown Source)
javax.swing.JPanel.<init>(Unknown Source)
javax.swing.JPanel.<init>(Unknown Source)
javax.swing.JPanel.<init>(Unknown Source)
javax.swing.JRootPane.createGlassPane(Unknown Source)
javax.swing.JRootPane.<init>(Unknown Source)
javax.swing.JApplet.createRootPane(Unknown Source)
javax.swing.JApplet.<init>(Unknown Source)
com.adaptiveplanning.ui.desktop.aptreetable.APTreeTableApplet.<init>(APTreeTableApplet.java:40)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
java.lang.reflect.Constructor.newInstance(Unknown Source)
java.lang.Class.newInstance0(Unknown Source)
java.lang.Class.newInstance(Unknown Source)
sun.applet.AppletPanel.createApplet(Unknown Source)
sun.plugin.AppletViewer.createApplet(Unknown Source)
sun.applet.AppletPanel.runLoader(Unknown Source)
sun.applet.AppletPanel.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

------------------------------------------------------------------------------

Name: AWT-EventQueue-0
State: BLOCKED on java.lang.Object@1c8c58 owned by: Thread-39
  Total blocked: 1  Total waited: 0

Stack trace:
javax.swing.UIManager.maybeInitialize(Unknown Source)
javax.swing.UIManager.getLookAndFeel(Unknown Source)
com.sun.java.swing.plaf.windows.DesktopProperty$WeakPCL.propertyChange(Unknown
Source)
java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
sun.awt.windows.WDesktopProperties.diffPropertyChanges(Unknown Source)
   - locked sun.awt.windows.WDesktopProperties@2a3135
sun.awt.windows.WDesktopProperties.access$100(Unknown Source)
sun.awt.windows.WDesktopProperties$DiffPropertyChanges.run(Unknown Source)
java.awt.event.InvocationEvent.dispatch(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This happens intermittently as the apple loads in the IE browser

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No deadlock
ACTUAL -
Sometimes deadlocks

REPRODUCIBILITY :
This bug can be reproduced occasionally.
Comments
EVALUATION The deadlock during applet construction is caused by creation of the JApplet on a thread which is not the Event Dispatch Thread. Unfortunately for compatibility reasons the init(), start(), stop(), and destroy() methods of applets are not called on the EDT. However, it seems that construction of the Applet object can probably safely be moved on to the EDT, since in the new Java Plug-In the code for resizing the applet and placing it in its containing frame was rewritten and moved on to the EDT for thread safety. This fix is only being made for the new Java Plug-In because the old Java Plug-In is very fragile in this area and we do not want to introduce risk for customers relying on it for compatibility reasons. An attempt was made to write a targeted test for this change, but this attempt was unsuccessful; the original race condition is hard to provoke. For this reason there is no explicit test case for this bug. Tested with the Pogo.com applets, NeuroDNA's NeuroKernel, the JavaFX samples, and other applets.
09-01-2009
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u14/6789085.0
09-01-2009
EVALUATION Here is the standard pattern for Swing standalone applications public class Pattern { private static void createGui() { final JFrame frame = new JFrame(); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(200, 200); frame.setLocationRelativeTo(null); frame.setVisible(true); } public static void main(String[] args) throws Exception { SwingUtilities.invokeAndWait(new Runnable() { public void run() { Pattern.createGui(); } }); } }
25-12-2008
EVALUATION Plugin team commented that they aware of the fact that Applet in initialized in incorrect thread and it can't be changed for compatibility reasons, so the only option for user is to create all Swing components on the right thread manually like we require for standalone applications
25-12-2008
EVALUATION Swing is a single-threaded toolkit, obviously plugin doesn't call JApplet.init() on Event Dispatch Thread there are two solutions for this problem: 1) User should wrap all Swing related code in JApplet.init() method with SwingUtilities.invokeAndWait() or invokeLater() 2) Plugin calls JApplet.init() on the correct thread reassign to the plugin team
25-12-2008