Event dispatching thread

The event dispatching thread (EDT) is a background thread used in Java to process events from the Abstract Window Toolkit (AWT) graphical user interface event queue. These events are primarily update events that cause user interface components to redraw themselves, or input events from input devices such as the mouse or keyboard. The AWT uses a single-threaded painting model in which all screen updates must be performed from a single thread. The event dispatching thread is the only valid thread to update the visual state of visible user interface components. Updating visible components from other threads is the source of many common bugs in Java programs that use Swing.[1] The event dispatching thread is called the primordial worker in Adobe Flash and the UI thread in .NET Framework and Android.

Contents

Swing and thread safety

Most AWT and Swing object methods are not thread safe: invoking them from multiple threads risks thread interference or memory consistency errors.[2] [3] To avoid these problems, Swing standards state that all user interface components should be created and accessed only from the AWT event dispatch thread.[4] A popular third-party Look and Feel named Substance goes as far as to refuse to instantiate any Swing component when not running within the Event Dispatch Thread,[5] to prevent such a coding mistake from occurring.

Executing code in the event dispatching thread

Other application threads can have code executed in the event dispatching thread by defining the code in a Runnable object and pass it to the SwingUtilities helper class or to the EventQueue. Two methods of these classes allow:

from the event dispatching thread.

The method invokeAndWait() should never be called from the event dispatching thread—it will throw an exception. The method SwingUtilities.isEventDispatchThread() or EventQueue.isDispatchThread() can be called to determine if the current thread is the event dispatching thread.

Worker design pattern

Another solution for executing code in the event dispatching thread is using the worker design pattern. The javax.swing.SwingWorker class, developed by Sun Microsystems, is an implementation of the worker design pattern, and as of Java 6 is part of standard Swing distribution. The open source project Foxtrot provides another synchronous execution solution similar to SwingWorker.

Samples 

SwingWorker<Document, Void> worker = new SwingWorker<Document, Void>() {
    public Document doInBackground() throws IOException {
        return loadXML(); // heavy task
    }
 
    public void done() {
        try {
            Document doc = get();
            display(doc);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
};
worker.execute();

If you use Groovy and groovy.swing.SwingBuilder, you can use doLater(), doOutside(), and edt(). Then you can write it more simple like this.

doOutside {
    def doc = loadXML() // heavy task
    edt { display(doc) }
}

Equivalents

Timer

You can also run the code in the event dispatching thread using javax.swing.Timer.

Equivalents

See also

References

  1. ^ This problem is not specific to Java Swing. There is the same issue in most Widget toolkits, as for example Windows Forms, where the BackgroundWorker class performs the same purpose as SwingWorker in Java.
  2. ^ "The Event Dispatch Thread". Sun Microsystems. Retrieved 2011-10-02. 
  3. ^ "Debugging Swing - is it really difficult?". Alexander Potochkin. Retrieved 2011-10-02. 
  4. ^ "Initial Threads". Sun Microsystems. Retrieved 2011-10-02. 
  5. ^ http://www.pushing-pixels.org/?p=368

External links

fonte: https://web.archive.org/web/20130906185917/https://en.wikipedia.org/wiki/Event_dispatching_thread