Is it safe to construct Swing/AWT widgets NOT on the Event Dispatch Thread?

Question

I've been integrating the Substance look and feel into my application and ran into several problems regarding it's internal EDT (Event Dispatch Thread) checking routines. Substance absolutely refuses to construct UI classes outside of the EDT. I've done plenty of Swing/AWT and I know most of the rules regarding the EDT. I use SwingWorker, SwingUtilties.invokeLater to modify components. I always though that components could be CONSTRUCTED outside of the EDT, but must be realized and manipulated on the EDT. In other words, you can construct and setup defaults in the background but the call to pack/setVisible must be EDT as well as any subsequent calls to manipulate the component.

The reason I ask is that I have a particularly "beefy" window to construct, involving many widgets, state, and resources (lots of icons). Previously, I constructed the window on the background method of a SwingWorker and made the window visible in the done method. Never had a single problem. Upon switching to Substance, the internal EDT checking bites me.

I've been able to refactor code to get around this. I can construct on the EDT which isn't a good solution since the entire application will block. I can also refactor even more and try my best to load all of the extra resources outside of the EDT.

Wrapping it up ... Is it safe to construct Swing/AWT widgets NOT on the Event Dispatch Thread?

Answer 1

No.

Simple reason is that even the EDT likes to deadlock in some rare cases and in general it's easy to deadlock the UI when using Swing (or so I've been told). I suggest you read these three articles from Kirill's (the Substance dev) blog:

• New article on Swing EDT violations
• Unwritten rule of working with Swing’s EDT
• Stricter checks on EDT violations in Substance

Answer 2

Sun has changed the rules in 2004 -- before, you were allowed to create the components outside the EDT and only had to move into the EDT once the component had been realized.

The new rule now reads:

To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread.

this blog post of mine gives more details, including links to other related articles. note that all official Sun examples have been rewritten and are very strict about this.

historically, it probably was the increasing availability of multi-core computers as desktop machines that motivated the re-formulation of the rule -- threading issues became more and more apparent on the client stack, and by being very strict on EDT guidelines, a lot of them can be prevented from the start.