Easier Swing Threading with SwingWorker
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.
The article covers why desktop applications need to be multi-threaded. It then shows how SwingWorker assists developers in implementing such solutions and includes detail on such features as intermediate results.
Insightful and detailed
There is just a small confusion in thread synchronization ("...inner classes... providing the information in the constructor helps your application to be more thread-safe") --> the example is thread safe because every UI change is made in the Swing thread, but the JLabel is shared the same way if you use a distinct class or an inner class.
Nevertheless, it's refreshing to leave the JEE world sometimes. The synchronization problems of Swing and other desktop UI API are interestings.