Event dispatching thread: Difference between revisions

Revision as of 17:57, 30 December 2023

Latest revision as of 19:30, 9 August 2025

(3 intermediate revisions by 2 users not shown)

Line 3:

The events are primarily update events that cause user interface [[Software componentry|components]] to redraw themselves, or input events from [[input device]]s such as the mouse or keyboard. The AWT uses a single-threaded painting [[Model (abstract)|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 [[Software bug|bugs]] in Java [[Computer program|programs]] that use [[Swing (Java)|Swing]].<ref>This problem is not specific to Java [[Swing (Java)|Swing]]. There is the same issue in most [[Widget toolkit]]s, as for example [[Windows Forms]], where the [[BackgroundWorker]] class performs the same purpose as [[SwingWorker]] in Java.</ref> The event dispatching thread is called the '''primordial worker''' in [[Adobe Flash]] and the '''UI thread''' in [[Standard Widget Toolkit|SWT]], [[.NET Framework]] and [[Android (operating system)|Android]].

== Message Looploop for serializing GUI accesses ==

A software application normally consists of multiple threads and a single GIT data structure. This means GIT is a shared data structure and some synchronization is needed to ensure that only one thread accesses it at a time. Though [[Abstract Window Toolkit|AWT]] and [[Swing (Java)|Swing]] expose the ([[Thread safety|thread unsafe]]) methods to create and access the GUI components and these methods are visible to all application threads, likewise in other GUI frameworks, only a single, Event Dispatching thread has the right to execute these methods.<ref>{{cite web

Line 12:

| url=http://weblogs.java.net/blog/alexfromsun/archive/2005/11/debugging_swing_1.html

| title=Debugging Swing - is it really difficult?

| publisher=[http://www.java.net/blogs/alexfromsun/ Alexander Potochkin]

| accessdate=2011-10-02

| archive-url=https://web.archive.org/web/20110805132240/http://weblogs.java.net/blog/alexfromsun/archive/2005/11/debugging_swing_1.html

Line 32:

There are various solutions for submitting code to the EDT and performing lengthy tasks without blocking the loop.

===Component Eventevent Handlershandlers (Listenerslisteners)===

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.)

Line 89:

* <code>android.os.AsyncTask</code> - [[Android (operating system)|Android]]

===Modal Executionexecution===

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. [https://stackoverflow.com/questions/3028842/how-can-swing-dialogs-even-work 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 '''[httphttps://foxtrot.sourceforge.net/docs/worker.php 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.

<syntaxhighlight lang="java">

button.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e) {

{

button.setText("Sleeping...");

public void actionPerformed(ActionEvent e)

{

button.setText("Sleeping...");

String text = null;

try {

text = (String) Worker.post(new Task() {

{

public Object run() throws Exception {

text = (String)Worker.post(new Task()

Thread.sleep(10000);

{

return "Slept !";

public Object run() throws Exception

}

{

});

Thread.sleep(10000);

} catch (Exception x) ...

return "Slept !";

}

});

}

catch (Exception x) ...

button.setText(text);

somethingElse();

}

});

</syntaxhighlight>

Line 130 ⟶ 124:

* [[Swing (Java)]]

* [[SwingWorker]]

* [[ComponentUpdateThread]]

==References==

Line 142 ⟶ 135:

* [http://download.oracle.com/javase/tutorial/uiswing/concurrency/worker.html SwingWorker] description from the Swing tutorial

* [http://tech.stolsvik.com/2009/03/awt-swing-event-pumping-and-targeting.html AWT/Swing event handling] article about event pumping, dispatch and processing, and the EDT

* [httphttps://foxtrot.sourceforge.net/ Foxtrot project home page]

{{DEFAULTSORT:Event Dispatching Thread}}