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. It is an example of the generic concept of event-driven programming, that is popular in many other contexts than Java, for example, web browsers, or web servers. The 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. The event dispatching thread is called the primordial worker in Adobe Flash and the UI thread in SWT, .NET Framework and Android.

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. It is an example of the generic concept of event-driven programming, that is popular in many other contexts than Java, for example, web browsers, or web servers. The 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. The event dispatching thread is called the primordial worker in Adobe Flash and the UI thread in SWT, .NET Framework and Android. ==Submitting user code to the EDT== There are various solutions for submitting code to the EDT and performing lengthy tasks without blocking the loop. ===Component event handlers (listeners)=== GUI components support the lists of callbacks, called Listeners, which are typically populated when the components are created. EDT executes the listeners when user excitates the components somehow (button is clicked, mouse is moved, item is selected, focus is lost, component resized and so on.) ====Samples==== SwingWorker worker = new SwingWorker () { 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 simply like this: doOutside { def doc = loadXML() // heavy task edt { display(doc) } } ====Equivalents==== System.ComponentModel.BackgroundWorker - .NET Framework flash.system.Worker - Adobe Flash android.os.AsyncTask - Android ===Modal execution=== SwingWorker is normally created for a lengthy tasks by EDT while handling callback (Listener) events. Spawning a worker thread, EDT proceeds handling current message without waiting the worker to complete. Often, this is not desirable. Often, your EDT handles a GUI component action, which demands the user to make a choice by means of another dialog, like JFileChooser, which pops up, stays responsive while user picks its option and action proceeds with selected file only after "OK" button is pressed. You see, this takes time (user responds in matter of seconds) and you need a responsive GUI (the messages are still pumped in EDT) during all this time while EDT is blocking (it does not handle newer, e.g. JFileChooser, messages in the queue before the dialog is closed and current component action is finished). The vicious cycle is broken through EDT entering a new message loop, which dispatches the messages as per normal until "modal dialog is over" arrives and normal message processing resumes from the blocked position in the component action. The open source Foxtrot project emulates the Swing message loop pumping to provide the "synchronous" execution mechanism for arbitrary user tasks, which proceeds only after the worker completes the task. button.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { button.setText("Sleeping..."); String text = null; try { text = (String) Worker.post(new Task() { public Object run() throws Exception { Thread.sleep(10000); return "Slept !"; } }); } catch (Exception x)... button.setText(text); somethingElse(); } }); Since Java 1.7, Java provides standard solution for custom secondary message loops by exposing createSecondaryLoop() in system EventQueue(). ==References==

Text derived from https://en.wikipedia.org/w/index.php?oldid=1318685647 under CC BY-SA 4.0; modifications have been made.