Swing and threads - An Introduction to Graphical User Interfaces with Java Swing - page 237

temporarily store the events. This is a data structure that handles the events in a
first-in-first-out manner.
Any newly incoming event is added at the end of the queue and then gradually
moves to the head where older events are taken out and processed. Processing an
event means to call a method (e.g. actionPerformed )ofthe appropriate listener.
This method then carries out some code as a reaction to the event. The latter hap-
pens in the event thread, not the main thread. Besides events that are processed
by those listeners defined by the programmer, the queue contains events coming
from listeners that are automatically assigned to Swing components. These in-
clude requests to repaint a component as a reaction to resizing it or clicking on a
menu.

■

20.2 Blocking a user interface

20.2.1 How blocking occurs

Our example application BlockingFrame shows how a lengthy operation can lead
to undesired effects. A BlockingFrame has a menu and a label which is glued cen-
trally into the frame's content pane. The label initially contains the text 'Nothing
happened'. The menu bar has one menu which contains the single item 'Start'.
A listener of type MenuListener monitors the menu item. This listener class is
defined as an internal class.
When the menu item is selected, the listener's actionPerformed method is
called. This method performs a lengthy job. We simulate the lengthy job by a
for-loop which is executed ten times. Inside the loop, the application waits half
a second (500 ms) using the sleep command from the class Thread .Inorder to
document the work, the text of the label is updated in every execution of the loop.
The texts reads 'Working' followed by the number of the loop variable. The same
text is also printed to console using System.out.println .Inaddition we print
the name of the thread that is currently running. After the last execution of the
loop the text is set to 'Done'. We expect that, after selecting 'Start' in the menu,
the label will display 'Nothing happened', 'Working 0', . . . , 'Working 9', 'Done'.
What we observe is different. After selecting the menu item 'Start' the menu
does not retract but remains visible for the duration of a lengthy job - five sec-
onds. The text of the label remains 'Nothing happened'. Clicking on the menu or
elsewhere on the frame has no effect. Resizing it will make the text of the label
and menu disappear. The GUI is said to be blocked as long as the lengthy job is
running. After five seconds the menu retracts and the label displays 'Done'. The
GUI reacts to the mouse again. On the console we can, however, see the messages
'Working i' to be printed every half second. We can also see that the code for the
lengthy work is not performed in the main thread but in the event thread. The
output is listed below. AWT-EventQueue-0 is the name given to the event thread
by the runtime system 1 . The first line is printed from inside the main method of
BlockingFrame , which is executed in the thread named main .

1

The internal names given to threads by the runtime system might be different on different
platforms or in different versions of the SDK.