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.
Uwe Zdun, Rafael Capilla, Huy Tran, Olaf Zimmermann Mar 09, 2014
Olav Maassen, Liz Keogh & Chris Matts Mar 08, 2014