Why SwingWorker? Why not just Thread or Runnable?

Question

What are the advantages of using SwingWorker instead of Thread or Runnable?

Answer 1

I think the documentation of the SwingWorker is pretty good:

An abstract class to perform lengthy GUI-interacting tasks in a dedicated thread.

When writing a multi-threaded application using Swing, there are two constraints to keep in mind: (refer to How to Use Threads for more details):

• Time-consuming tasks should not be run on the Event Dispatch Thread. Otherwise the application becomes unresponsive.
• Swing components should be accessed on the Event Dispatch Thread only.

These constraints mean that a GUI application with time intensive computing needs at least two threads: 1) a thread to perform the lengthy task and 2) the Event Dispatch Thread (EDT) for all GUI-related activities. This involves inter-thread communication which can be tricky to implement.

SwingWorker is designed for situations where you need to have a long running task run in a background thread and provide updates to the UI either when done, or while processing. Subclasses of SwingWorker must implement the doInBackground() method to perform the background computation.

surely you can do this using Thread, Runtime and SwingUtilities (invokeLater) but it's easier and probably less error prone using the SwingWorker class.

Answer 2

Thread and Runnable were part of Java 1.0; they're as good as they were back then.

The new concurrency classes distill all that's been learned about multi-threading since then (thank you, Doug Lea and others). Writing multi-threaded code is terribly difficult. The new concurrency classes, including SwingWorker, try to make that easier.

Start by noting the generics for strong typing. There's a mechanism built in to publish and process both final and intermediate results.

It'd be possible to mimic these with Thread and Runnable, but SwingWorker has done it for you.