Swing event-dispatch model

 First, when the user interacts with Swing components, whether it is clicking on a button or resizing a window, the Swing toolkit generates event objects that contain relevant event information, such as event source and event ID. The event objects are then placed onto a single event queue ordered by their entry time. While that happens, a separate thread, called the event-dispatch thread, regularly checks the event queue's state. As long as the event queue is not empty, the event-dispatch thread takes event objects from the queue one by one and sends them to the interested parties. Finally, the interested parties react to the event notification by processing logic such as event handling or component painting. Figure 1 illustrates how this works.

 Figure 1. Swing event-dispatch model

Since the event-dispatch thread executes all event-processing logic sequentially, it avoids undesirable situations such as painting a component whose model state is partially updated. This is great news for Swing developers because they can assume that only one thread, the event-dispatch thread, will process the event-handling code. If two event-dispatch threads worked on the event queue, Swing developers would need to write additional code for thread safety. Similarly, executing user interface-related code in any thread other than the event-dispatch thread can lead to unexpected behaviors.