Window Systems
All modern window toolkits are designed around the concept of having an event loop waiting for
window events. Xview, SunView, X11, MS Windows, Motif, CDE, AWT, Swing, etc., are all
based on an event loop. Basically, the thread in question will sit in a call to read(), waiting for
input. The user may push a button or move the mouse, or a socket or pipe may signal data ready.
All of these are encoded as events. (In the different toolkits, different events may be registered
with the event loop. Java allows only mouse events and keyboard input events in the AWT and
Swing.)
When that event is read by the event loop, the event loop then dispatches the event to the
appropriate method. In X11, CDE, etc., the programmer will register specific functions to run
when specific events occur. In both Swing and the AWT, events are always dispatched to one of a
small number of known methods. If you subclass Applet and create a button, pushing that button
will call the Button method actionPerformed(). You (presumably) have specialized that
method for your subclass to do what you want.
In a Swing program, the main thread runs main() (as usual) and it typically lays out the
components for a window and makes them appear by calling either show() or setVisible().
As soon as the first Swing window is shown, an event dispatch thread is also created to handle
events. All event callbacks run in this thread.
The AWT is not thread-safe. This will come as a great surprise to many people (the authors
included). There were plenty of indications that it was, and plenty of sample programs in topics
and manuals that assumed it was, but it isn't.
In a window system that is thread-safe, any method may be called on any object in the toolkit in
one thread while any other method is running on any other object (or the same method and object).
The results might not always make sense, but it would be legal and would produce the same
results as if you had called the methods from the same thread. This is a good thing, because you
can call methods from any thread at any time. This is also a bad thing because it will slow down
the window system quite a bit.
The future of Java is not in the AWT, so we won't spend much time on it. (A sample AWT
program that mimics our Swing example is on the Web.) Swing is the new toolkit that you'll be
using to do all of your Java windows work and Swing is most specifically not thread-safe! This is
bad because you can't call methods from any thread at random. This is good because you're less
likely to make the silly mistakes noted above.
Its one drawback is largely mitigated by the inclusion of two methods, invokeAndWait() and
invokeLater(). These two methods place any operation you want onto a queue that the
window thread will run from its read/execute loop. The first function, invokeAndWait(),
places the event onto the event queue and waits until it completes. The second, invokeLater(),
places the event onto the queue and returns immediately (Figure 11-3). The event will then get
processed some unknown time later. You will probably not use invokeAndWait() very often,
and obviously you would never call it from the event dispatch thread.
Figure 11-3. Threads Using invokeLater() with the Swing Toolkit
Search WWH :
