After installing "Java for OS X 2013-004" update, Java apps don't work anymore as expected

Does anyone know specifically what causes this problem? I'm a developer who wants to fix our now-broken application, but I can't find any resources to point me in the right direction when debugging.

The PaperCut site indicated that changing the look and feel might help, but that does not help me. We're using a custom L&F here with a bunch of extra ComponentUI classes, so I can't just change to another one.

Hi Mike,

Can you give us a lead as to what fixed the problem on Geneious ?,

I switched the LAF but still the whole app I am supporting is stuck ...

tx,

Noam

You will need to ask at Geneious (www.geneious.com). They released an update that replaces the affected version. They must know what the problem is, but have not said anything on their support pages about how they solved it. I imagine they spent a stressful time sorting it out.

- Mike DS

I am following those threads too, but changing the laf does not help my app

one thing i found out the swing thread is somehow blocked, and takes the next event in the queue

only when I resize the application window size

I have the same problem. Matlab stopping working!!!!!!!!!!!!!!!!

Apple is such a loser that they cannot offer quick solution!!!!!!!!!

My thesis work is serious delayed!!!!!!

I have the same problem. Affected programs include FigTree and Dendroscope. A day of lost work. Thanks a lot Apple! Maybe in 10 years OS X will be ready for the enterprise..

Apple is such a loser that they cannot offer quick solution!!!!!!!!!

Again, so many people here are blaming Apple, but please keep in mind that Apple is really not involved here. The update code is entirely created by Oracle, no matter whether you downloaded it from Oracle's site, allowed Java to update itself or accepted an Apple software update that provided it. Apple, at most, did no more than provide an important third-party software update.

If you want to be mad at someone, that's your prerogative, but at least choose the right people. You should be annoyed at Oracle, for allowing Java to get into such a bad state with security that major overhauls have become necessary, and at the maker of whatever Java-based software stopped working, for not keeping it better updated.

Thomas A Reed wrote:

Again, so many people here are blaming Apple, but please keep in mind that Apple is really not involved here. The update code is entirely created by Oracle, no matter whether you downloaded it from Oracle's site, allowed Java to update itself or accepted an Apple software update that provided it. Apple, at most, did no more than provide an important third-party software update.

java -version

java version "1.6.0_51"

Java(TM) SE Runtime Environment (build 1.6.0_51-b11-456-11M4508)

Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-456, mixed mode)

from java.com:

Why I cannot find Java 6 for Mac OS X here?

For Java versions 6 and below, Apple supplies their own version of Java. For Mac OS X 10.6 and below, use the Software Update feature (available on the Apple menu) to check that you have the most up-to-date version of Java 6 for your Mac. For issues related to Apple Java 6 on Mac, contact Apple Support.

Mr. Reed,

Do you have any evidence that, in fact, Oracle supplied the code for this update? Up until last year, all of Java 6 was supplied by Apple; this was NOT the Sun/Oracle version of Java. The Java Look and Feel was entirely written by Apple.

It's possible that, when Apple stopped supplying their own version of Java, they turned over the code to Oracle for them to update. However, with the latest update (to 1.6.0_51), the system properties java.vendor = "Apple, Inc.", and java.vendor.url.bug = "http://bugreport.apple.com".

Apple used to supply their own version of Java 6, and it caused problems for people and headaches for Apple, because their updates were invariably late. They had to fold the updates into their codebase, and that took time. Apple has since washed their hands of that, and they provide Java 6 through the same old interfaces only as legacy support. It's all Oracle code at this point, as evidenced by the fact that it was perfectly timed with Oracle's release.

Really, folks, this Apple-bashing is not only not based on reality, it's also completely and utterly useless and unproductive. Java is a complete mess, and only Oracle can be blamed for that.

Aside from the relatively minor fact that Apple used to be responsible for Java 6, Java 6 and Java 7 are very different. They have significantly different codebases. You don't suppose that that might not be more relevant to the problem?

In any case, I'm tired of trying to bring some reason into this topic, so I'm bowing out. If blaming Apple somehow helps you to get your problem fixed, more power to you.

Hi, I'm the developer at Biomatters who tracked this down for Geneious. Here is what I found.

It has always been the case that the Swing documentation says that all Swing methods must be called only from within the Swing thread unless the method's API doc specifically says that method is thread-safe. Up to now there have been no problems seen calling some methods that do not say "thread-safe" in the javadoc and that seem like they don't cause actions in the GUI and should be safe. In particular, it is common to not think about threads when you initialize the Swing GUI layout theme by calling UIManager.setLookAndFeel() at the very start of running an application, before you display anything.

With this update to Java 6 we have found that you must wrap the call to UIManager.setLookAndFeel to ensure it is called from within the Swing thread, just like you do with other Swing calls. Some small test programs that don't do that still seem to work, but you can no longer get away with it.

It is probably common practice to set the application's look and feel when it starts up. If you do, change that to do it in the Swing (also known as the dispatch or the GUI) thread.

There may be other Swing methods that are not documented as thread-safe which used to let you get away with that too, so check your use of Swing to ensure that you are properly using the methods that are not labeled in their JavaDoc as thread-safe.