Threads and Swing

 

Threads and Swing

Print-friendly Version Threads and Swing  This article about multithreading in Swing was archived in April 1998. A month later, we published another article, "Using a Swing Worker Thread", expanding on the subject. For a better understanding of how multithreading works in Swing, we recommend that you read both articles. Note: In September 2000 we changed this article and its example to use an updated version of SwingWorker that fixes a subtle threading bug. By Hans Muller and Kathy Walrath The Swing API was designed to be powerful, flexible, and easy to use. In particular, we wanted to make it easy for programmers to build new Swing components, whether from scratch or by extending components that we provide. For this reason, we do not require Swing components to support access from multiple threads. Instead, we make it easy to send requests to a component so that the requests run on a single thread. This article gives you information about threads and Swing components. The purpose is not only to help you use the Swing API in a thread-safe way, but also to explain why we took the thread approach we did. Here are the sections of this article: The single-thread rule: Swing components can be accessed by only one thread at a time. Generally, this thread is the event-dispatching thread. Exceptions to the rule: A few operations are guaranteed to be thread-safe. Event dispatching: If you need access to the UI from outside event-handling or drawing code, then you can use the SwingUtilities invokeLater()or invokeAndWait() method. Creating threads: If you need to create a thread -- for example, to handle a job that's computationally expensive or I/O bound -- you can use a thread utility class such as SwingWorker or Timer. Why did we implement Swing this way?: This article ends with some background information about Swing's thread safety. Here's the rule: Once a Swing component has been realized, all code that might affect or depend on the state of that component should be executed in the event-dispatching thread. This rule might sound scary, but for many simple programs, you don't have to worry about threads. Before we go into detail about how to write Swing code, let's define two terms: realized and event-dispatching thread. Realized means that the component's paint() method has been or might be called. A Swing component that's a top-level window is realized by having one of these methods invoked on it: setVisible(true), show(), or (this might surprise you) pack(). Once a window is realized, all components that it contains are realized. Another way to realize a component is to add it to a container that's already realized. You'll see examples of realizing components later. The event-dispatching thread is the thread that executes drawing and event-handling code. For example, the paint() and actionPerformed() methods are automatically executed in the event-dispatching thread. Another way to execute code in the event-dispatching thread is to use the SwingUtilities invokeLater() method. There are a few exceptions to the rule that all code that might affect a realized Swing component must run in the event-dispatching thread: A few methods are thread-safe: In the Swing API documentation, thread-safe methods are marked with this text: This method is thread safe, although most Swing methods are not. An application's GUI can often be constructed and shown in the main thread: The following typical code is safe, as long as no components (Swing or otherwise) have been realized: public class MyApplication { public static void main(String[] args) { JFrame f = new JFrame("Labels"); // Add components to // the frame here... f.pack(); f.show(); // Don't do any more GUI work here... } } All the code shown above runs on the "main" thread. The f.pack() call realizes the components under the JFrame. This means that, technically, the f.show() call is unsafe and should be executed in the event-dispatching thread. However, as long as the program doesn't already have a visible GUI, it's exceedingly unlikely that the JFrame or its contents will receive a paint() call before f.show() returns. Because there's no GUI code after the f.show() call, all GUI work moves from the main thread to the event-dispatching thread, and the preceding code is, in practice, thread-safe. An applet's GUI can be constructed and shown in the init() method: Existing browsers don't draw an applet until after its init() and start() methods have been called. Thus, constructing the GUI in the applet's init() method is safe, as long as you never call show() or setVisible(true) on the actual applet object. By the way, applets that use Swing components must be implemented as subclasses of JApplet, and components should be added to the JApplet content pane, rather than directly to the JApplet. As for any applet, you should never perform time-consuming initialization in the init() or start() method; instead, you should start a thread that performs the time-consuming task. The following JComponent methods are safe to call from any thread: repaint(), revalidate(), and invalidate(). The repaint() and revalidate() methods queue requests for the event-dispatching thread to call paint() and validate(), respectively. The invalidate() method just marks a component and all of its direct ancestors as requiring validation. Listener lists can be modified from any thread: It's always safe to call the addListenerTypeListener() and removeListenerTypeListener() methods. The add/remove operations have no effect on an event dispatch that's under way. NOTE: The important difference between revalidate() and the older validate() method is that revalidate() queues requests that might be coalesced into a single validate() call. This is similar to the way that repaint() queues paint requests that might be coalesced. Most post-initialization GUI work naturally occurs in the event-dispatching thread. Once the GUI is visible, most programs are driven by events such as button actions or mouse clicks, which are always handled in the event-dispatching thread. However, some programs need to perform non-event-driven GUI work after the GUI is visible. Here are some examples: Programs that must perform a lengthy initialization operation before they can be used: This kind of program should generally show some GUI while the initialization is occurring, and then update or change the GUI. The initialization should not occur in the event-dispatching thread; otherwise, repainting and event dispatch would stop. However, after initialization the GUI update/change should occur in the event-dispatching thread, for thread-safety reasons. Programs whose GUI must be updated as the result of non-AWT events: For example, suppose a server program can get requests from other programs that might be running on different machines. These requests can come at any time, and they result in one of the server's methods being invoked in some possibly unknown thread. How can that method update the GUI? By executing the GUI update code in the event-dispatching thread. The SwingUtilities class provides two methods to help you run code in the event-dispatching thread: invokeLater(): Requests that some code be executed in the event-dispatching thread. This method returns immediately, without waiting for the code to execute. invokeAndWait(): Acts like invokeLater(), except that this method waits for the code to execute. As a rule, you should use invokeLater() instead of this method. This page gives you some examples of using this API. Also see the BINGO example in The Java Tutorial, especially the following classes: CardWindow, ControlPane, Player, and OverallStatusPane.   Using the invokeLater() Method   You can call invokeLater() from any thread to request the event-dispatching thread to run certain code. You must put this code in the run() method of a Runnable object and specify the Runnable object as the argument to invokeLater(). The invokeLater method returns immediately, without waiting for the event-dispatching thread to execute the code. Here's an example of using invokeLater(): Runnable doWorkRunnable = new Runnable() { public void run() { doWork(); } }; SwingUtilities.invokeLater(doWorkRunnable);   Using the invokeAndWait() Method   The invokeAndWait() method is just like invokeLater(), except that invokeAndWait() doesn't return until the event-dispatching thread has executed the specified code. Whenever possible, you should use invokeLater() instead of invokeAndWait(). If you use invokeAndWait(), make sure that the thread that calls invokeAndWait() does not hold any locks that other threads might need while the call is occurring. Here's an example of using invokeAndWait(): void showHelloThereDialog() throws Exception { Runnable showModalDialog = new Runnable() { public void run() { JOptionPane.showMessageDialog( myMainFrame, "Hello There"); } }; SwingUtilities.invokeAndWait (showModalDialog); } Similarly, a thread that needs access to GUI state, such as the contents of a pair of text fields, might have the following code: void printTextField() throws Exception { final String[] myStrings = new String[2]; Runnable getTextFieldText = new Runnable() { public void run() { myStrings[0] = textField0.getText(); myStrings[1] = textField1.getText(); } }; SwingUtilities.invokeAndWait (getTextFieldText); System.out.println(myStrings[0] + " " + myStrings[1]); }   If you can get away with it, avoid using threads. Threads can be difficult to use, and they make programs harder to debug. In general, they just aren't necessary for strictly GUI work, such as updating component properties. However, sometimes threads are necessary. Here are some typical situations where threads are used: To perform a time-consuming task without locking up the event-dispatching thread. Examples include making extensive calculations, doing something that results in many classes being loaded (initialization, for example), and blocking for network or disk I/O. To perform an operation repeatedly, usually with some predetermined period of time between operations. To wait for messages from clients. You can use two classes to help you implement threads: SwingWorker: Creates a background thread to execute time-consuming operations. Timer: Creates a thread that executes some code one or more times, with a user-specified delay between executions.   Using the SwingWorker Class   The SwingWorker class is implemented in SwingWorker.java, which is not included in any of our releases, so you must download it separately. SwingWorker does all the dirty work of implementing a background thread. Although many programs don't need background threads, background threads are sometimes useful for performing time-consuming operations, which can improve the perceived performance of a program. To use the SwingWorker class, you first create a subclass of it. In the subclass, you must implement the construct() method so that it contains the code to perform your lengthy operation. When you instantiate your SwingWorker subclass, the SwingWorker creates a thread but does not start it. You invoke start() on your SwingWorker object to start the thread, which then calls your construct() method. When you need the object returned by the construct() method, you call the SwingWorker's get() method. Here's an example of using SwingWorker: ...//in the main method: final SwingWorker worker = new SwingWorker() { public Object construct() { return new expensiveDialogComponent(); } }; worker.start(); ...//in an action event handler: JOptionPane.showMessageDialog (f, worker.get()); When the program's main() method invokes the start() method, the SwingWorker starts a new thread that instantiates ExpensiveDialogComponent. The main() method also constructs a GUI that consists of a window with a button. When the user clicks the button, the program blocks, if necessary, until the ExpensiveDialogComponent has been created. The program then shows a modal dialog containing the ExpensiveDialogComponent. You can find the entire program in MyApplication.java.   Using the Timer Class   The Timer class works with an ActionListener to perform an operation one or more times. When you create a timer, you specify how often the timer should perform the operation, and you specify which object is the listener for the timer's action events. Once you start the timer, the action listener's actionPerformed() method is invoked one or more times to perform its operation. The actionPerformed() method defined in the Timer's action listener is invoked in the event-dispatching thread. That means that you never have to use the invokeLater() method in it. Here's an example of using a Timer to implement an animation loop: public class AnimatorApplicationTimer extends JFrame implements ActionListener { ...//where instance variables ...//are declared: Timer timer; public AnimatorApplicationTimer(...) { ... // Set up a timer that calls this // object's action handler. timer = new Timer(delay, this); timer.setInitialDelay(0); timer.setCoalesce(true); ... } public void startAnimation() { if (frozen) { // Do nothing. The user has // requested that we stop // changing the image. } else { //Start (or restart) animating! timer.start(); } } public void stopAnimation() { //Stop the animating thread. timer.stop(); } public void actionPerformed (ActionEvent e) { //Advance the animation frame. frameNumber++; //Display it. repaint(); } ... }   There are several advantages in executing all of the user interface code in a single thread: Component developers do not have to have an in-depth understanding of threads programming: Toolkits like ViewPoint and Trestle, in which all components must fully support multithreaded access, can be difficult to extend, particularly for developers who are not expert at threads programming. Many of the toolkits developed more recently, such as SubArctic and IFC, have designs similar to Swing's. Events are dispatched in a predictable order: The runnable objects enqueued by invokeLater() are dispatched from the same event queue as mouse and keyboard events, timer events, and paint requests. In toolkits where components support multithreaded access, component changes are interleaved with event processing at the whim of the thread scheduler. This makes comprehensive testing difficult or impossible. Less overhead: Toolkits that attempt to carefully lock critical sections can spend a substantial amount of time and space managing locks. Whenever the toolkit calls a method that might be implemented in client code (for example, any public or protected method in a public class), the toolkit must save its state and release all locks so that the client code can grab locks if necessary. When control returns from the method, the toolkit must regrab its locks and restore its state. All applications bear the cost of this, even though most applications do not require concurrent access to the GUI. Here's a description, written by the authors of the SubArctic Java Toolkit, of the problem of supporting multithreaded access in a toolkit: It is our basic belief that extreme caution is warranted when designing and building multi-threaded applications, particularly those which have a GUI component. Use of threads can be very deceptive. In many cases they appear to greatly simplify programming by allowing design in terms of simple autonomous entities focused on a single task. In fact in some cases they do simplify design and coding. However, in almost all cases they also make debugging, testing, and maintenance vastly more difficult and sometimes impossible. Neither the training, experience, or actual practices of most programmers, nor the tools we have to help us, are designed to cope with the non-determinism. For example, thorough testing (which is always difficult) becomes nearly impossible when bugs are timing dependent. This is particularly true in Java where one program can run on many different types of machines and OS platforms, and where each program must work under both preemptive or non-preemptive scheduling. As a result of these inherent difficulties, we urge you to think twice about using threads in cases where they are not absolutely necessary. However, in some cases threads are necessary (or are imposed by other software packages) and so subArctic provides a thread-safe access mechanism. This section describes this mechanism and how to use it to safely manipulate the interactor tree from an independent thread. The thread-safe mechanism they're referring to is very similar to the invokeLater() and invokeAndWait() methods provided by the SwingUtilities class