Java Platform: New Event Model

Java Development Kit (JDK) 1.1 introduced (among other things) a new event handling model and Swing components. If you have JDK 1.0 code that you want to upgrade to the new event model or convert to Swing, or if you want to write new programs using JDK 1.1 or later, the information in this article is for you.

Why Upgrade?

There can be a number of reasons to upgrade your code. One good reason is to take advantage of new features and improved functionality. For example, the JDK 1.1 event handling model is more flexible, more powerful, and easier to use; and Swing offers a sleek forms-based look and feel that is more efficient and has more capabilities. Once you upgrade to the new event model, your code will compile under JDK 1.2 (it might need some additional tweaking), which leaves you free to take advantage of JDK 1.2 features and functionality.

Another reason to upgrade is that Swing components were introduced in JDK 1.1 and require the new event model. If you want to use Swing components, you have to migrate to at least JDK 1.1.

JDK 1.1 Event Model

The transition from the JDK 1.0 to 1.1 event models is very straightforward once you understand the new design. In JDK 1.0 only component classes have event handling methods, and so no other objects can handle events.

In JDK 1.1 the java.awt.Component event handling methods listed below are deprecated, and replaced by a full set of event listener interfaces and adapter classes. Any class can implement one or more event listener interfaces or use the adapter classes, and this means event handling is not limited to component objects.

Deprecated Methods

• handleEvent()
• action()
• gotFocus()
• lostFocus()
• keyDown()
• keyUp()
• mouseEnter()
• mouseExit()
• mouseMove()
• mouseDrag()
• mouseDown()
• mouseUp()

New Interfaces and Classes

The event listener interfaces extend java.util.EventListener and define methods that accept a corresponding java.awt.AWTEvent subclass. For example, the ActionListener interface has an actionPerformed() method that takes an ActionEvent object as a parameter.

Every event listener interface with more than one method has a corresponding adapter class that you can extend or use as an inner class. With interfaces, you have to implement all the methods. If your application does not need all of the methods, it can be easier to extend the adapter class and implement only the method or methods you need.

JDK 1.1 introduced most of the event listener interfaces in the following list, but EventQueueListener and InputMethodListener are both new in JDK 1.2.

How to Code It

There are different approaches to putting event handling code into a program. You can use the event listening interfaces, the adapter classes, or a combination or interfaces and classes; and you can structure your program so the back-end event handling code is in a separate class or combined in the same class with the other user interface code.

• If the event listeners you need have one or (maybe) two methods, the easiest thing to do might be to implement the event listener interfaces.
• If the event listeners you need have many methods that you do not need, the easiest thing to do might be to use the adapter classes.

Once you decide whether you want to use the event listener interfaces, adapter classes, or a combination of interfaces and adapters, you can decide whether to separate the back-end event handling code from the user interface code.

If you follow the links below, you will find explanations and code examples that show these different approaches. The links go to the same file, just to different locations. If you want to, you can start with the first link which takes you to the top of the file, and read straight through to the end where there is a link that returns you to the heading AWT to Swing just below.

Listening for Events
Using Adapter Classes

AWT to Swing

Swing 1.0.2 extends the Abstract Window Toolkit (AWT) with a full set of GUI components and services, pluggable look and feel capabilities, and assistive technology support. The Swing architecture is based on the AWT architecture, which makes it easy to port AWT-component programs to Swing. If you wonder why you should use Swing or convert an AWT-component program to Swing, consider these things:

• Swing components are more efficient and have a cleaner look and feel. Most Swing components are lightweight, which means they do not rely on user interface code that is native to the underlying operating system they run on. Being lightweight, they are more efficient than heavyweight components that rely on native user interface code.
• If you want a cross-platform look and feel, you can easily plug it into your program, and if you expect the application to run only on a certain platform, you can easily plug that look and feel in too. You can also set your application to plug the look-and-feel in at run time.
• Swing applications can support assistive technologies such as screen readers, screen magnifiers, and speech recognition devices, which make Swing applications accessible to a wide-range of persons with special needs.

Making the Changes

In many cases, it takes only a few adjustments to source code to convert AWT components to Swing. The list below summarizes how the AWT source code for the demonstration application from the Exploring the AWT Layout Managers article was changed to use Swing components.

• Swing import statement added:
  import java.awt.swing.*;
• Swing container used:
  JFrame
• Swing components used:
  JButton, JPanel, JTextField, JLabel
• Main program specifies the look and feel:
  UIManager.setLookAndFeel(
  UIManager.getCrossPlatformLookAndFeelClassName());

Here are the AWT and Swing versions of the source code:

JDK 1.1 using AWT components
JDK 1.1 using Swing components

Using a Content Pane

If you look at the LayoutExample constructor in the Swing version of the source code (excerpted below), you see calls to the getContentPane() method of JFrame for setting the layout manager and adding components.

Components are not added directly to a JFrame, but to its content pane. Because the layout manager controls the layout of components, it is set on the content pane where the components reside. A content pane provides functionality that allows lightweight and heavyweight components to work together in Swing.

public LayoutExample() {
  getContentPane().setLayout(new GridLayout(1,2));
  setFont(new Font("Helvetica", Font.PLAIN, 14));

  p1 = new JPanel();
  p1.setLayout(new GridLayout(8,1));
  p2 = new JPanel();

  p1.setBackground(Color.gray);
  p2.setBackground(Color.white);
  getContentPane().add(p1);
  getContentPane().add(p2);

Different Methods

Some Swing components have different methods from their AWT counterparts. If you just change the component name without checking the methods, the compiler will point out all the AWT component methods that are not valid in Swing. In most cases, it is simply a matter of browsing the Java docs to find the correct name or parameter list for the equivalent method in Swing.

Conclusion

You have nothing to lose and everything to gain by upgrading your JDK 1.0 code to the JDK 1.1 event model and converting to Swing components. It is not difficult once you understand the new architecture and know where to make the changes.

© 1994-2005 Sun Microsystems, Inc.