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: