Having given you a taste of how event handling works, we want to turn to a more general discussion of event handling in Java. As we briefly mentioned earlier, event handling in Java is object oriented, with all events descending from the EventObject class in the java.util package. (The common superclass is not called Event since that is the name of the event class in the old event model. Although the old model is now deprecated, its classes are still a part of the current AWT.) The EventObject class has a subclass AWTEvent, which is the parent of all AWT event classes. shows the inheritance diagram of the AWT events.

Inheritance diagram of the AWT event classes

Java graphics 08fig05

Some of the Swing components generate event objects of yet more event types; these directly extend EventObject, not AWTEvent. You can even add your own custom events by subclassing EventObject or one of the other event classes, as you will see at the end of this chapter. The event objects encapsulate information about the event that the event source communicates to its listeners. When necessary, you can then analyze the event objects that were passed to the listener object, as we did in the button example with the getSource and getActionCommand methods. Some of the AWT event classes are of no practical use for the Java programmer. For example, the AWT inserts PaintEvent objects into the event queue, but these objects are not delivered to listeners. Java programmers should override the paintComponent method to control repainting. Here is a list of those AWT event types that are actually passed to listeners. 

ActionEvent ItemEvent AdjustmentEvent KeyEvent ComponentEvent MouseEvent ContainerEvent MouseWheelEvent FocusEvent TextEvent WindowEvent

You will see examples of all of these event types in this chapter and the next. The javax.swing.event package contains additional events that are specific to Swing components. We will cover some of them in the next chapter. There are fourteen listener interfaces altogether in the java.awt.event package: 

ActionListener MouseListener AdjustmentListener MouseMotionListener ComponentListener MouseWheelListener ContainerListener TextListener FocusListener WindowListener ItemListener WindowFocusListener KeyListener WindowStateListener

You have already seen the ActionListener and WindowListener interface. Although the javax.swing.event package contains many more listener interfaces that are specific to Swing user interface components, it still uses the basic AWT listener interfaces extensively for general event processing. Seven of the AWT listener interfaces, namely, those that have more than one method, come with a companion adapter class that implements all the methods in the interface to do nothing. (The remaining four interfaces have only a single method each, so there is no benefit in having adapter classes for these interfaces.) For example, the WindowAdapter class has seven do-nothing methods. Here is a list of the names of these adapter classes: 

ComponentAdapter MouseAdapter ContainerAdapter MouseMotionAdapter FocusAdapter WindowAdapter KeyAdapter

Obviously, there are a lot of classes and interfaces to keep track of-it can all be a bit overwhelming. Fortunately, the principle is simple. A class that is interested in receiving events must implement a listener interface. It registers itself with the event source. It then gets the events that it asked for, and processes them through the methods of the listener interface.

NOTE: Java graphics cplus_icon People coming from a C/C++ background may be wondering: why the proliferation of objects, methods, and interfaces needed for event handling? You are used to doing GUI coding by writing callbacks with generic pointers or handles. This won't work in Java. The Java event model is strongly typed: the compiler watches out that events are sent only to objects that are capable of handling them.