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.
Community comments
Insightful and detailed
by Cyril Gambis,
Insightful and detailed
by Cyril Gambis,
Your message is awaiting moderation. Thank you for participating in the discussion.
The article is well written and very detailed (sometimes a bit too verbose) and the example is well chosen.
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.