Easier Swing Threading with SwingWorker

| by Scott Delap Follow 0 Followers on Jan 29, 2007. Estimated reading time: 1 minute |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

Threading is an essential topic in respect to the development of desktop applications. In Swing there are a number of utility libraries to make this programming task easier such as Foxtrot and Spin. The topic is also regularly covered at JavaOne. In a new tutorial, John O'Conner walks developers through using another utility, SwingWorker, which has been included in the core JRE for the first time with the release of Java 6.

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Insightful and detailed by Cyril Gambis

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you