FOR THE MOST part, Swing is not thread-safe, meaning that Swing components can
only be accessed from a single thread. First, we'll discuss why Swing is not thread safe
and then we'll discuss the ramifications a single-threaded design has for developers using Swing.
WHY SWING IS NOT THREAD-SAFE
Developing multithreaded applications is not easy, even in Java. Designing a thread-safe toolkit
is no simple matter; for example, determining how to synchronize access to a class can be a complex
undertaking (see Lea, D., Concurrent Programming in Java, Addison-Wesley, Reading, MA, 1997).
Likewise, extending thread-safe classes is somewhat of an art of its own and can be fraught with
peril when undertaken by developers who are not experts at threads programming, which includes
most developers. One of the main reasons that Swing is not thread safe is to simplify the task
of extending its components.
Another reason that Swing is not thread-safe is due to the overhead involved in obtaining and
releasing locks and restoring state. All applications that use a thread-safe GUI toolkit, whether
they are multithreaded or not, must pay the same performance penalty incurred by a thread-safe toolkit.
The use of threads increases the difficulty associated with debugging, testing, maintenance, and
extensibility. For example, testing and maintenance, which are normally arduous tasks become even
more so for most multithreaded applications.
Some Swing component methods do support multithreaded access. For example, the JComponent
methods repaint, revalidate, and invalidate all queue requests, which are placed
on the event dispatch thread and therefore may be called from any thread. Also, event listener lists
can have listeners added and removed from multiple threads. Finally, some component methods are
synchronized; for example, the JCheckBoxMenuItem.setState() is synchronized and therefore may be
invoked from multiple threads.
Ramifications of Swing's Single-Threaded Design
The main consequence of Swing's single-threaded design is as follows: Swing components can only be
accessed from the event dispatch thread once a component is available for painting onscreen.
The event dispatch thread is the thread that invokes callback methods such as paint and update in
addition to event handler methods defined in event listener interfaces. For example, implementors of
the ActionListener and PropertyListener interfaces have their actionPerformed
and propertyChange methods invoked on the event dispatch thread.
Technically, Swing components can be accessed from multiple threads before the component's peer has been
created, meaning that the component is available for painting onscreen. This means for instance, that
components can be constructed and manipulated in an applet's init method as long as the components are
not made visible before they are manipulated.
SwingUtilities.invokeLater AND invokeAndWait
Because the AWT and, therefore, Swing are event driven toolkits, it is natural to implement the updating
of a visible GUI in callback methods. For example, if a list of items needs to be updated when a button
is activated, the updating of the list is typically implemented in the actionPerformed method of
an event listener attached to the button.
Sometimes, however, it may be necessary to update Swing components from a thread other than the event
dispatch thread. For instance, if the list of items mentioned above is populated with data obtained from
a database or over the Internet, there may be a perceptible delay from the time the button is activated
until the list is updated. If the information retrieval is implemented within the actionPerformed
method, the button will remain painted in its pressed state until the call to actionPerformed returns. Not
only will it take a while for the button to pop up, but in general, lengthy operations should not be
performed in event handler methods because other events cannot be dispatched until the event handler
method in question returns.
At times, it may be better to retrieve information or perform other time-consuming operations on a separate
thread, which allows the user interface to update immediately and frees the event dispatch thread to dispatch
other events. Fortunately, Swing offers two mechanisms that supports such a scenario.
The SwingUtilities class provides two methods: invokeLater and invokeAndWait that
queue a runnable object on the event dispatch thread. When the runnable object makes its way to the front
of the event dispatch queue, its run method is invoked. In effect, this allows an arbitrary block of code
from another thread to be invoked from the event dispatch thread.
Before illustrating the invokeLater and invokeAndWait methods, let's first look at an
applet that misbehaves by updating a Swing component on a thread other than the event dispatch thread.
The applet shown in Figure 1 contains a button and a progress bar. When the button is activated, some
lengthy operation to retrieve information is simulated. Once the information (an integer value)
is retrieved, it is used to update the applet's progress bar.
Figure 1. Updating Swing components from multiple threads.
The picture on the left in Figure 1 shows the applet in its initial state. The picture on the right shows
the applet after the start button has been activated, information has been retrieved, and the progress bar
has been updated.
The applet adds an action listener to the button, and the listener creates a new thread that continuously
retrieves information and updates the progress bar. The information retrieval is simulated by sleeping for
half a second, and the thread obtains a reference to the progress bar from the applet itself
(see Listing 1).
After the button's listener starts the thread, it sets the enabled state of the button to false.
This is a valid operation, because the actionPerformed method is invoked on the event dispatch thread.
However, setting the value of the progress bar in the GetInfoThread is a risky proposition,
because the progress bar is being updated from a thread other than the event dispatch thread.
The applet shown in Figure 1 is listed in its entirety in
The correct way to update the progress bar in the applet shown in Figure 1 is to use
SwingUtilities.invokeLater() (or alternatively, invokeAndWait()). The constructor for
the GetInfoThread class (see Listing 3)
is modified to instantiate a runnable object that obtains a reference to the progress bar from the applet and
updates its value. The run method of the GetInfoThread class invokes
SwingUtilities.invokeLater and passes a reference to the runnable object.
Note that SwingUtilities.invokeLater() may throw an InterruptedException, so the exception
must be caught whenever invokeLater() is invoked.
A revised version of the applet shown in Figure 1 is listed in its entirety in
SwingUtilities.invokeAndWait(), like invokeLater(), queues a runnable object on the event
dispatch thread. However, whereas invokeLater() returns immediately after it has queued the
runnable object, invokeAndWait() waits until the run method of the runnable object has been
started before returning. The invokeAndWait method is useful when information must be retrieved
from a component before another operation can be performed on another thread.
For example, the applet listed in Listing 4 updates the value of the progress bar regardless of whether
the new value is the same as the current value of the progress bar. It would be ever-so-slightly more
efficient if the progress bar's value were only updated when the new value differs from the current
value of the progress bar. Modifying the applet to do so will afford us the opportunity to investigate
the invokeAndWait method.
First, the GetInfoThread class is modified to create two runnable objects—one that gets the
current value of the progress bar, and another that sets the value of the progress bar (see
Next, the run method of the GetInfoThread class is modified to obtain the current value of the
progress bar by using invokeAndWait() (see
SwingUtilities.invokeAndWait() is used to obtain the current value of the progress bar, and
invokeLater() is used to set the value of the progress bar. The call to InvokeAndWait
will not return until the run method of the getValue runnable object returns.
SwingUtilities.invokeAndWait() may throw one of two exceptions: either an
InterruptedException, or an InvocationTargetException. The exceptions must be caught
whenever invokeAndWait() is used or the method in which the call is made must have a throws clause.
The complete revised applet is listed in
One important distinction between invokeLater() and invokeAndWait() is that
invokeLater() can be called from the event dispatch thread, whereas invokeAndWait() cannot.
The problem with calling invokeAndWait() from the event dispatch thread is that
invokeAndWait() blocks the thread that it is called from until the runnable object is
dispatched from the event dispatch thread and its run method invoked. If invokeAndWait() is
called from the event dispatch thread, thread deadlock will occur because invokeAndWait() is
waiting for events to be dispatched, but because it is called from the event dispatch thread, events
cannot be dispatched until invokeAndWait() returns.