Don't Over-Work Your Swing Thread

I know at least three different teams that I've worked with in the past that screw up Swing thread handling. Frankly, they should all know better. People, there is no such thing as a single-threaded Java Swing application. Fortunately, the Java 6 standard library is getting an addition that should help developers with this problem: the SwingWorker API.

One common mistake of desktop application programmers is misusing the Swing event dispatch thread (EDT). They either unknowingly access user interface (UI) components from non-UI threads or simply disregard the consequences. The result is that applications become unresponsive or sluggish because they perform long-running tasks on the EDT instead of on separate worker threads. Long-running computations or input/output (I/O) bound tasks should never run on the Swing EDT. Finding problematic code may not always be simple, but the Java Platform, Standard Edition 6 (Java SE 6) makes it easier to fix such code by providing the javax.swing.SwingWorker class.

One of the reasons I tend to prefer SWT over Swing is that it seems to be better about throwing nasty exceptions when you try and step over the UI thread. Neither is perfect, but I tend to get more exceptions when I do stupid stuff in SWT. If I do something stupid in Swing, I get a grey box and a frozen UI.