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 appl

Answer 1

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

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

Answer 2

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!

Answer 3

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)

Answer 4

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.

Answer 5

I answered this at https://stackoverflow.com/a/17226346/2507292 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.