previous chapter table of contents next chapter

Event Models

Java has a number of event models, differing in various subtle ways. All of these involve an object (an event source ) generating an event in response to some change of state, either in the object itself (for example, if someone has changed a field), or in the external environment (such as when a user moves the mouse). At some earlier stage, a listener (or set of listeners) will have registered interest in this event. When the event source generates an event, it will call suitable methods on the listeners with the event as parameter. The event models all have their origin in the Observer pattern from Design Patterns , by Eric Gamma et al., but this is modified by other pressures, such as Java Beans.

There are low-level input events, which are generated by user actions when they control an application with a graphical user interface. These events ”of type KeyEvent and MouseEvent -are placed in an event queue. They are removed from the queue by a separate thread and dispatched to the relevant objects. In this case, the object that is responsible for generating the event is not responsible for dispatching it to listeners, and the creation and dispatch of events occurs in different threads.

Input events are a special case caused by the need to listen to user interactions and always deal with them without losing response time. Most events are dealt with in a simpler manner: an object maintains its own list of listeners, generates its own events, and dispatches them directly to its listeners. In this category fall all the semantic events generated by the AWT and Swing toolkits, such as ActionEvent, ListSelectionEvent , etc. There is a large range of these event types, and they all call different methods in the listeners, based on the event name . For example, an ActionEvent is used in a listener's actionPerformed() method of an ActionListener. There are naming conventions involved in this, specified by Java Beans.

Java Beans is also the influence behind PropertyChange events, which get delivered whenever a Bean changes a "bound" or "constrained" property value. These are delivered by the event source calling the listener's PropertyChangeListener 's propertyChange() method or the VetoableChangeListener 's vetoableChange() method. These are usually used to signal a change in a field of an object, where this change may be of interest to the listeners either for information or for vetoing.

Jini objects may also be interested in changes in other Jini objects, and might like to be listeners for such changes. The networked nature of Jini has led to a particular event model that differs slightly from the other models already in Java. The differences are caused by several factors:

  • Network delivery is unreliable ”messages may be lost. Synchronous methods requiring a reply may not work here.
  • Network delivery is time-dependent ”messages may arrive at different times to different listeners. As a result, the state of an object as perceived by a listener at any time may be inconsistent with the state of that object as perceived by others. Passing complex object state across the network may be more complex to manage than passing simpler information.
  • A remote listener may have disappeared by the time the event occurs. Listeners have to be allowed to time out, like services do.
  • Java Beans can require method names and event types that vary and can use many classes. This requires a large number of classes to be available across the network, which is more complex than a single class with a single method with a single event type as parameter (the original Observer pattern used a single class with only one method, for simplicity).

A Programmer[ap]s Guide to Jini Technology
A Programmer[ap]s Guide to Jini Technology
ISBN: 1893115801
Year: 2000
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net