Core JFC Java Foundation Classes 2nd edition - Read

152 Chapter 2 Frames, Labels, and Buttons
look-and-feel can be rendered. The paint method is almost never invoked
directly by application code—usually, it is called as a result of the component
being made visible or being exposed after being covered by another window
that is subsequently moved to reveal it. These user interface events cause the
windowing system to deliver an internal event which is translated to an event
in the Java virtual machine and then placed in the AWT event queue and processed
by the event thread. In other words, when a component draws itself in
its paint method, it is executing code in the AWT event thread. As a result,
therefore, all Swing applications are multi-threaded, even the simple one
shown in Listing 2-6.
Armed with this knowledge, you should now be able to see why there is a
possible thread-safety issue with the example code that we have been looking
at. When the fourth button is added to the window and the window is
resized, the code that performs these actions is running in the virtual
machine's main thread. What happens if, at exactly the same time, the user
does something that will require the window to repaint itself, such as hiding
the main window and then exposing it, thus causing a paint event to be
placed into the AWT event queue? Theoretically, there is a small chance that
the event thread could dispatch this event and start painting the applications
main window at exactly the same time as the main thread is changing the
windows layout. Figure 2-24 shows a possible sequence of actions that
clearly shows the multithreading aspect of this apparently simple example.
Figure 2-24 Potential multithreading conflicts in a Swing application.