The IRIS demo application developed for JavaOne 2007 (http://iris.dev.java.net/ , http://swinglabs.org/iris/) exhibits a problem where the application occasionally fails to start successfully; it will not load any users' albums nor perform many other actions.

The symptom is lost property change notifications deep in the SwingWorker code: changes to the "state" bound property were not propagating out, causing the Swing Application Framework to fail to notify the "succeeded" / "failed" listeners on its Tasks, causing Iris to fail to update the web page after loading a user's albums from Flickr.

The root cause is the use of a one-shot Swing timer in the DoSubmitAccumulativeRunnable inner class of SwingWorker. For some reason, occasionally the first javax.swing.Timer created and started in the system will fail to fire. This will cause all subsequent calls to SwingWorkerPropertyChangeSupport.firePropertyChange() to be enqueued on a list that will never be processed.

It seems that if the first Timer successfully fires, then all subsequent ones will.

Commenting out the definition of DoSubmitAccumulativeRunnable.submit(), using the superclass's version which calls SwingUtilities.invokeLater(), works around the problem.

Working with ###@###.### indicates that the problem appears to be that in some circumstances the per-AppContext TimerQueue thread fails to start.

The problem is related to the changes to the Swing Timer and TimerQueue from 5053997. Reverting these classes in a JDK 7 workspace to the pre-5053997 versions (as well as dependent classes) works around the problem.