Light As A Feather
by Jonathan Knudsen

One of the reasons Java is exciting is that it changes so fast. The Java platform lives in "Internet time," which is a cartoonish speeded-up world that spins around Silicon Valley. Since Java was introduced in late 1995, it's grown at an astonishing rate. As a student of the Java platform, you barely have enough time to learn one release before another comes out. It's particularly hard to keep up if you're learning Java in your spare time.

One area of radical change is Java's user interface (UI) toolkit. In JDK 1.0 and JDK 1.1, the Abstract Windowing Toolkit (AWT) provided the windows, buttons and other components that make up a user interface. In the world of Java 2 (JDK 1.2), however, Swing is the new UI toolkit. AWT and Swing are about as closely related as a Yugo and a Ferrari. They're both UI toolkits, but Swing's capabilities and performance far outperform AWT.

Having just learned AWT, you may be dismayed to have a big mountain of information about Swing to assimilate. Don't be discouraged, however--Swing was specifically designed so that it works like AWT in many cases.

For people who are already familiar with AWT, one of the most confusing things about Swing is its use of lightweight components. If you have done any reading about Swing, you have probably discovered that the AWT components you've been using now carry the stigma of being heavyweight. What does it all mean? In this column, I'll explain what heavyweight and lightweight components are and how you should use them.

Everything Is a Component

Remember, no matter how much Java looks like an operating system (OS), it isn't (yet). The Java platform sits on top of an existing OS. To get to the resources of the OS, like the disk drive, network card, or display, Java uses native, platform-specific code. At some point, then, any UI toolkit built in Java has to deal with a specific OS to display its windows and components.

Clumsy Old AWT

This has the effect that applications in AWT have controls that look appropriate for the underlying OS. If you run an AWT application on Solaris, you'll get the standard X Windows buttons, lists, and other controls. Run the same application in Windows, and you'll get standard Windows controls. However, this is one of those things where it's not clear if it's a bug or a feature. Some people think this is how a cross-platform application should work, changing chameleon-like to fit in with the host OS. Other people believe that a cross-platform application should look the same on different platforms.

Regardless, the peer approach to AWT components has some serious drawbacks. First, it's very hard to port AWT from platform to platform. While it's true that most graphic OS's have basically the same visual elements, they do vary in appearance and behavior. Getting AWT to work reliably on different platforms, each with its own set of peers, was a serious problem.

The other penalty of the peer approach is performance. You might think that using the OS's native components would result in fast Java applications, but exactly the opposite is true. Running all Java or all native code is pretty fast, but if you have a lot of interaction between Java and the underlying OS, it slows things down. An AWT window full of components has many peers, one for each component. Each of these represents some interaction between your application and the underlying OS. For complicated interfaces, AWT can be a real dog. Furthermore, native components are not necessarily very efficient in their memory usage.

Components with peers are called heavyweight, because they tend to drag your application down into the muck. In AWT, all components are heavyweight.

Swing Be Nimble, Swing Be Quick

As a matter of fact, Swing is written purely in Java. It relies upon the native code in AWT for the top level containers. Aside from this, however, the rest of AWT's peer system has been discarded. But because Swing is pure Java, it's a no-brainer to port it to a different platform.

Another consequence of having Swing components draw themselves is that they look the same on different platforms. Furthermore, it's easy to change the appearance of the components--you just have them draw something else. Swing expands this concept into Pluggable Look & Feels, where the entire appearance of an application, including all of its components, can be changed at the drop of a hat.

Like Oil and Water

If a heavyweight component and a lightweight component overlap in any way, the heavyweight component will always appear on top. For example, a heavyweight button will always appear on top of any lightweight components, including things like menus.

The rule of thumb is that you should use either heavyweight or lightweight components, but not both. If you're converting existing code, you may as well do it all at once, or at least in large container-sized chunks. Trying to get heavyweight and lightweight components to work together is probably more trouble than it's worth.

Paint Carefully

If you override paint() in a Swing container, you should call super.paint() to take care of painting the child components. Alternately, you can override paintComponent() instead of paint(). The paintComponent() method is called by paint(); its sole responsibility is painting the component.

Show Me The Money

import java.awt.*;
import java.awt.event.*;

import javax.swing.*;

public class HosedMenu
    extends JFrame {
  public static void main(String[] args) {
    JFrame f = new HosedMenu();
    f.addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent we) { System.exit(0); }
    });
    f.setVisible(true);
  }
  
  public HosedMenu() {
    super("HosedMenu v1.0");
    setSize(200, 200);
    setLocation(200, 200);
    
    // Add lightweight and heavyweight buttons to the content pane.
    getContentPane().setLayout(new GridLayout(2, 1));
    getContentPane().add(new JButton("Lightweight JButton"));
    getContentPane().add(new Button("Big Bad Button"));
    
    // Add a menu bar.
    JMenuBar mb = new JMenuBar();
    JMenu file = new JMenu("File", true);
    file.add("This");
    file.add("menu");
    file.add("is");
    file.add("hosed.");
    mb.add(file);
    setJMenuBar(mb);
  }
}

Run the example; you'll see a small window with two buttons and a menu bar. The top button is lightweight; the bottom button is heavyweight. Click on the File menu. The bottom part of this lightweight menu will be obscured by the heavyweight button. (Interestingly, if you make the frame window small enough, the menu will actually be created heavyweight. Swing realizes it can't draw the whole menu on the frame window's drawing surface and creates a heavyweight component that will fit the entire menu.)

The second example, TouchyFeely, shows how the appearance of Swing's lightweight components can be changed at runtime. It shows two panels with a handful of controls on each. The left half of the window is made from Swing components, while the right half contains AWT components. A menu allows you to choose from the look and feels that are available on your platform. The standard JDK includes one called Metal, one that looks like Motif, and one that looks like Windows. As you select these different look and feels, the Swing components will change their appearance to reflect the look and feel. The AWT components, on the right, won't change at all. They are heavyweight components; the underlying OS is responsible for drawing them and there is no way to change their appearance from Java.

import java.awt.*;
import java.awt.event.*;

import javax.swing.*;

public class TouchyFeely
    extends JFrame {
  public static void main(String[] args) {
    JFrame f = new TouchyFeely();
    f.addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent we) { System.exit(0); }
    });
    f.setVisible(true);
  }
  
  public TouchyFeely() {
    super("TouchyFeely v1.0");
    setSize(400, 200);
    setLocation(200, 200);
    
    // Create two panels of controls.
    Container content = getContentPane();
    content.setLayout(new GridLayout(1, 2));
    // Create a Swing panel.
    JPanel jp = new JPanel();
    jp.add(new JCheckBox("JCheckBox"));
    String[] names = new String[] { "Tosca", "Scarpia", "Cavaradossi" };
    jp.add(new JComboBox(names));
    jp.add(new JList(names));
    jp.add(new JButton("JButton"));
    jp.add(new JLabel("JLabel"));
    jp.add(new JTextField("JTextField"));
    content.add(jp);
    // Create an AWT panel.
    Panel p = new Panel();
    p.add(new Checkbox("Checkbox"));
    Choice choice = new Choice();
    choice.add("Tosca");
    choice.add("Scarpia");
    choice.add("Cavaradossi");
    p.add(choice);
    List list = new List();
    list.add("Tosca");
    list.add("Scarpia");
    list.add("Cavaradossi");
    p.add(list);
    p.add(new Button("Button"));
    p.add(new Label("Label"));
    p.add(new TextField("TextField"));
    content.add(p);
    
    // Add a menu bar.
    JMenuBar mb = new JMenuBar();
    JMenu file = new JMenu("Look & Feel", true);
    ButtonGroup buttonGroup = new ButtonGroup();
    
    final UIManager.LookAndFeelInfo[] info =
        UIManager.getInstalledLookAndFeels();
    for (int i = 0; i < info.length; i++) {
      JRadioButtonMenuItem item = new
          JRadioButtonMenuItem(info[i].getName(), i == 0);
      final String className = info[i].getClassName();
      item.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent ae) {
          try { UIManager.setLookAndFeel(className); }
          catch (Exception e) { System.out.println(e); }
          SwingUtilities.updateComponentTreeUI(TouchyFeely.this);
        }
      });
      buttonGroup.add(item);
      file.add(item);
    }
    
    mb.add(file);
    setJMenuBar(mb);
  }
}

There's not a whole lot in this example. Most of it involves creating the two panels full of controls. The tricky part is in creating the menu that controls the look and feel of the application. The call to UIManager's static getInstalledLookAndFeels() method gives us an array of objects describing the available look and feels. A menu item is created from each available look and feel. For each menu item, an associated ActionListener sets the new look and feel.

Conclusion

Download the Source Code.