This week: the AWT 1.0 event model and ‘Don’t make that pass!’

Welcome to JavaWorld‘s newest resource for Java developers: the Java Q&A column. If you’re losing sleep over Java, start making a list of the questions that plague you. Be sure to tune in weekly for answers from the Java experts at Random Walk Computing — Wall Street’s leading Java consulting shop. They’ll be on hand to impart masterful answers to a variety of your most unbeatable Java questions. And be sure to visit the Java Q&A index page for links to previous Qs & As.

There is a difference: the difference between handleEvent() and action() in the AWT 1.0 event model

Q: What’s the difference between the handleEvent() and action() methods in the AWT 1.0 event model?

A: All the events that a component may receive are first sent to the component’s handleEvent() method. The default implementation of handleEvent() delegates the handling to more event-specific handlers. In the case of action events, it delegates to the component’s action() method. Generally, you would override action() in a component subclass and handle the action event there. That’s the brief answer; now let’s look at a more complete description of the AWT 1.0 event model.

The AWT 1.0 event model follows a ripple metaphor. Suppose someone clicks on a Button. The Button‘s Peer receives notification from the operating system (Solaris, Windows, and so on) and calls the Button‘s deliverEvent(), which calls the Button‘s postEvent(), which calls handleEvent(), which in turn calls action().

Now, in the case of a simple Button, its action() just returns false after doing nothing. But you could subclass Button with YourButton, and override action() to do something. Whether you return true (completely handled) or false (not yet completely handled) depends on whether or not other, enclosing, components are supposed to act on the event.

If the Button‘s action() returns true, then its handleEvent() will also return true and its postEvent() will not ripple the event further. But if the Button‘s action() returns false, then its handleEvent() will also return false and its postEvent() will now ripple the event to its parent, which is the component containing the Button (a Canvas or a Panel, for example). The same sequence of events occurs in the parent component, and if the event is not completely handled by the parent, it is passed to the parent’s enclosing component, and so on, until it is completely handled (some component’s action() returns true) or until it reaches the topmost window.

Now, handleEvent(java.awt.event.Event evt) is basically a large switch/case statement — it calls the appropriate handler based on the type of the event evt. For evt == java.awt.event.Event.ACTION_EVENT, handleEvent(evt) returns the value returned by calling action(evt, evt.arg). For evt == java.awt.event.Event.KEY_PRESS, handleEvent(evt) returns the value returned by calling keyDown (evt, evt.key). Note that only one handler is called for any given event type.

So, to answer your question, in the Java 1.0 AWT event model, the default behavior is: For every evt that reaches a component, the component’s handleEvent(evt) dispatches evt to one of the component’s default handlers. In the case of java.awt.event.Event.ACTION_EVENTs, the handler is action(evt, evt.arg).

Don’t make that pass! Passing initialization parameters between servlets

First of all, the Servlet API does not provide a way for some servlet (call it Source) to specify initialization parameters for some other servlet (Target). What would happen if Target were called before Source?

Target should have its own initialization parameters specified through the servlet engine. If it needs information from Source, then it should have setX() methods that Source can call.

Secondly, how should Source get a reference to Target in the first place? ServletContext.getServlet() is a dangerous method. For one thing, it takes control away from the servlet engine. Once Source has a reference to Target, for example, the servlet engine will not be able to shut down or restart Target without worrying that Source is still using it. Moreover, the getServlet() method is a security risk. For instance, if Target has a JDBC Connection object for a sensitive database, then Source might be able to make mischief by calling Target‘s methods and using its fields directly.

Version 2.1 of the Servlet API addresses this issue with the RequestDispatcher interface. Until your servlet engine supports 2.1, though, you won’t be able to use RequestDispatcher. Since I don’t know exactly what you are trying to do, I cannot recommend a specific alternative. I can suggest that you find out if your servlet engine supports features like chaining, JavaServer Pages, or Server Side Include with servlets.

For more information about the Servlet API try: https://java.sun.com/products/servlet/index.html

If you can’t wait for your servlet engine to support the most current specification, and you are a member of the Java Developer Connection, you can work with Sun’s Early Access version of the Java Servlet Development Kit 2.1, available at: https://developer.java.sun.com/developer/earlyAccess/jsdk/index.html