Chapter 2. (Introduction) Swing Mechanics. Easy for reading, Click here!

Subpages: 1. JComponent properties, size, and positioning 
2.  Event handling and dispatching 
3. Multithreading
4. Timers
5. AppContext service
6. Inside Timers & the TimerQueue
7. JavaBeans architecture
8. Fonts, Colors, Graphics and text
9. Using the Graphics clipping area
10. Graphics debugging
11. Painting and validation
12. Focus Management
13. Keyboard input, KeyStrokes, and Actions
14. SwingUtilities

2.2    Event handling and dispatching

Events occur anytime a key or mouse button is pressed. The way components receive and process events has not changed from JDK1.1. There are many different types of events that Swing components can generate, including those in java.awt.event and even more in javax.swing.event. Many of the new Swing event types are component-specific. Each event type is represented by an object that, at the very least, identifies the source of the event, and often carries additional information about what specific kind of event it is, and information about the state of the source before and after the event was generated. Sources of events are most commonly components or models, but there are also different kinds of objects that can generate events.

As we discussed in the last chapter, in order to receive notification of events, we need to register listeners with the target object. A listener is an implementation of any of the XXListener classes (where XX is an event type) defined in the java.awt.event, java.beans, and  javax.swing.event packages. There is always at least one method defined in each interface that takes a corresponding XXEvent as parameter. Classes that support notification of XXEvents generally implement the XXListener interface, and have support for registering and unregistering those listeners through the use of addXXListener() and removeXXListener() methods respectively. Most event targets allow any number of listeners to be registered with them. Similarly, any listener instance can be registered to receive events from any number of event sources. Usually classes that support XXEvents provide protected fireXX() methods used for constructing event objects and sending them to the event handlers for processing.

2.2.1    class javax.swing.event.EventListenerList

EventListenerList is an array of XXEvent/XXListener pairs. JComponent and each of its decendants use an EventListenerList to maintain their listeners. All default models also maintain listeners and an EventListenerList. When a listener is added to a Swing component or model, the associated event's Class instance (used to identify event type) is added to its EventListenerList array, followed by the listener itself. Since these pairs are stored in an array rather than a mutable collection (for efficiency purposes), a new array is created on each addition or removal using the System.arrayCopy() method. When events are received, the list is walked through and events are sent to each listener with a matching type. Because the array is ordered in an XXEvent, XXListener, YYEvent, YYListener, etc. fashion, a listener corresponding to a given event type is always next in the array. This approach allows very efficient event-dispatching routines (see section 2.7.7). For thread safety the methods for adding and removing listeners from an EventListenerList synchronize access to the array when it is manipulated.

JComponent defines its EventListenerList as a protected field called listenerList so that all subclasses inherit it. Swing components manage most of their listeners directly through listenerList.

2.2.2    Event-dispatching thread

All events are processed by the listeners that receive them within the event-dispatching thread (an instance of java.awt.EventDispatchThread). All painting and component layout is expected to occur within this thread as well. The event-dispatching thread is of primary importance to Swing and AWT, and plays a key role in keeping updates to component state and display in an app under control.

Associated with this thread is a FIFO queue of events -- the system event queue (an instance of java.awt.EventQueue). This gets filled up, as any FIFO queue, in a serial fashion. Each request takes its turn executing event handling code, whether this be updating component properties, layout, or repainting. All events are processed serially to avoid such situations as a component's state being modified in the middle of a repaint. Knowing this, we must be careful not to dispatch events outside of the event-dispatching thread. For instance, calling a fireXX() method directly from a separate thread of execution is unsafe. We must also be sure that event handling code, and painting code can be executed quickly. Otherwise the whole system event queue will be blocked waiting for one event process, repaint, or layout to occur, and our application will appear frozen or locked up.