Swing Application stuck following Apple Java update 1.6.0_51

Question

We have a Java Swing client application. It's installed as a Java Web Start applet and as a install4j installer.
Since Apple released the latest Java 6 upgrade our application gets stuck immediately after Login Dialog is displayed on both Installer and Web Start versions. We disabled the dialog, the application still got stuck immediately after the start. We also tried to use different Look&Feels, as there are some reports that this fixes the issue, it didn't help.
We currently suspect that this is some kind of Swing related bug in this version of JRE.
We do not have this issue on Oracle's 1.7.0_25 JRE.

We know that this update caused a lot of issues, has anyone found the fix for this?

Here is the last part of the stack-trace of EDT thread:

"AWT-EventQueue-1" prio=8 tid=000000002a1abc00 nid=0xb1d3f000 in Object.wait() [00000000b1d3d000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:485)
    at java.awt.EventQueue.getNextEvent(EventQueue.java:558)
    - locked <000000000686af80> (a java.awt.EventQueue)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:263)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:205)
    at java.awt.Dialog$1.run(Dialog.java:1049)
    at java.awt.Dialog$3.run(Dialog.java:1101)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Dialog.show(Dialog.java:1099)
    at java.awt.Component.show(Component.java:1615)
    at java.awt.Component.setVisible(Component.java:1567)
    at java.awt.Window.setVisible(Window.java:843)
    at java.awt.Dialog.setVisible(Dialog.java:984)

Link to the Apple's latest update information:
http://support.apple.com/kb/HT5797

According to release notes:

Multiple vulnerabilities existed in Java 1.6.0_45, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues were addressed by updating to Java version 1.6.0_51

Fitted

Which version you are using? – Gemination

They gave the patch for this in java7u43.Have you tried this by installing the latest release of java? – Gemination

The issue is with version 1.6.0_51, Apple's Java distribution, not the Oracle's Java. We don't control user's environment, so we need to solve the issue on this specific distribution – Fitted

We are too having weird issues with Apple's 1.6.0_51, and can reproduce them on Oracle's 1.7.0_25. For us, configuring webstart to show the console "fixes" all issues.Does that make any difference in your scenario? – Reis

@RafaelChaves we don't have those issues with Oracle's 1.7.0_25. – Fitted

Answer 1

This issue has been resolved by Apple releasing a revised version of these updates: http://support.apple.com/kb/DL1572 (10.7, 10.8+) http://support.apple.com/kb/DL1573 (10.6-only)

Pleat

that fixed it, reinstalled the java package from the dmg. Note that I already had _51. – Depilate

Answer 2

I noticed that 1.6.0_51 exposed missing dependencies in my jnlp in a few cases. The errors were inapparent in previous versions, possibly due to lazy loading. As a concrete example, the jnlp for my local copy of the jfreechart java-web-start demo included the well-known dependencies, jfreechart-1.0.14.jar and jcommon-1.0.17.jar. The javaws GUI noted an exception due to a missing iText-2.1.5.jar. In another case, a missing commons-math-2.2.jar failed silently. Absent detailed knowledge of the vulnerabilities fixed in 1.6.0_51, stricter dependency checking may be a reasonable hypothesis.

Olla

Does the application continue to run locally, without JWS? – Olla

No, it's stuck in JWS, installer, local dev environment (IntelliJ), everywhere. Doesn't look like JWS is causing it – Fitted

@LeonidB that looks like a healthy EDT stack trace, wonder if the problem is not elsewhere and an exception is going unnoticed/muted. – Reis

Answer 3

I answered this at https://mcmap.net/q/753762/-how-does-java-for-os-x-2013-004-affect-break-swing-applications The short form is that you have to wrap your call to UIManager.setLookAndFeel so it is run in the Swing thread. All Swing methods that are not labeled "thread-safe" in their JavaDoc must be run in that thread. Previous versions of Java did not seem to break if you did not do that, and it is easy not to think about it when setting the look and feel once at the start of your program. There may be other methods that are more strict about it too, but this is the one that bit us.

Aesthesia

@Wyatt - Try putting all of the UIManager method calls you use inside the Swing thread and see if that allows Buddi to work properly again. – Aesthesia

+1 See also Initial Threads. – Olla

Answer 4

My experiences seem to agree with Mike C's; however I found that any reference to UIManager seems to break the application. Specifically, adding any properties to UIManager (used by Quaqua to configure various options) will break it, as will setting any look and feel via UIManager.

(Source: I am the author of Buddi (http://buddi.digitalcave.ca), and today I started to get multiple bug reports from users reporting this issue. By adding a flag to optionally disable all reference to UIManager, I have got it to work again, albeit losing all the nice Mac looks. Hopefully Apple will release a fix to this soon...)

Edit: thank you Sidney, that suggestion worked. Very much appreciated!

Deel

Answer 5

In our case, we were able to restore our application to working condition by removing this line:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

Flavorous

You shouldn't have to omit this if you do it on the event dispatch thread. – Olla