Java Reference
In-Depth Information
Chapter 6. Java Core APIs
Event Handling
Packages
java.awt.event, javax.swing.event, java.util
(some classes)
Use:
J2SE (delegation model since JDK1.1)
Overview
Event handling allows two or more objects to communicate about a change of state within a system. In an
event-based system, one object acts as the event producer, and creates an event object to represent some change in
its state. It then passes the event to one or more registered receivers by calling some method on each receiver
object.
Event handling has been part of Java since the beginning. It is part of the AWT and, since J2SE v1.2, has also
been part of Swing. Event handling plays an important role in many of the Java APIs, including AWT, Swing,
and JavaBeans. Therefore, support for event-handling is available in the
java.util package
.
As of JDK 1.1, the current event handling model was introduced, the delegation model. It was designed to be
simple, flexible, and allow for a more robust system. Application code and GUI code can now be easily separated
and can be changed independently of each other. The introduction of specialized event types and listeners made
compile-time type-checking available.
Event handling happens this way. Each event type has its own
Event
class. The
Event
source, which is where an
event might occur, such as a Component, keeps a list of listeners that have registered with the source, stating they
are interested in any event that occurs at that source. When an event occurs, the Event source instantiates an
Event
object and sends it to the listeners for that event-specific interface. To do this, it invokes a listener method
on each of the listeners passing the
Event
object as an argument.
All
events extend from
java.util.EventObject
, which keeps a reference to the source of the event. Specific
types of events add functionality; for instance, the
ActionEvent
contains the
ActionCommand
, which can be set
on the source.
The event listeners are interfaces that define the methods the source can call when a certain condition occurs; for
instance, when a button is clicked or a mouse is moved. These interfaces all extend the interface
java.util.EventListener
.
The event sources don't need to implement an interface or extend some class to be a source. However, they must
keep a list of event listeners who have registered for events from this source. The listeners are registered with the
source by calling
add
XXX
Listener(
XXX
Listener
) . To remove them from the list, call
remove
XXX
Listener(
XXX
Listener)
.
XXX
is replaced by the name of the event type.
Generally speaking, event sources can be unicast (only one listener allowed) or multicast (multiple listeners
allowed). Within AWT and Swing, all event sources are multicast. To make things easier, a specialized
Multicaster exists,
java.awt.AWTEventMulticaster
. The
AWTEventMulticaster
provides an efficient and
thread-safe multicast event dispatching for the AWT events defined in the
java.awt.event
package [JLS].
The
AWTEventMulticaster
implements all AWT event listener interfaces so it can be used for any of the AWT
events. The
AWTEventMulticaster
constructor takes two event listeners. When a new listener is added, a new
AWTEventMulticaster
is created passing the current
AWTEventMulticaster
and the new listener as arguments.
This mechanism chains
AWTEventMulticasters
together. To propagate an event, each multicaster calls the
listener method on its two children: one is an event handler with a listener method, the other is the next
AWTEventMulticaster
in the chain). This is how event multicasting is achieved.
Swing uses a different class, instead of
AWTEventMulticaster
. The class
javax.swing.event.EventListenerList
can even be used for keeping a list of listeners of an unknown type.
When one event source has listeners of different types,
EventListenerList
is responsible for maintaining the
entire list of listeners.
