The Swing Tool Set

By Mark Andrews

The article titled "Introducing Swing" explained what Swing is (an extension of AWT) and what it isn't (a replacement for the AWT tool set).

This article takes a broader, more topographical overview of Swing. It lists and describes all the UI component classes used in Swing (and some of the most important non-UI classes, too), and it introduces some of the interfaces that Swing components implement.

It also describes and illustrates the inheritance hierarchy into which Swing's classes are organized.

To see what all of Swing's UI components look like, and to find out where to look for more information about each one, see the article titled "Component Gallery."

The Swing component hierarchy is similar in some ways to the AWT hierarchy. But on close examination, you'll see quite a few differences.

The Swing tool set is a comprehensive library of more than 250 classes and more than 75 interfaces for creating lightweight, 100% Pure Java GUI components.

Swing has more than twice as many components as AWT -- it is a comprehensive library of more than 250 classes and more than 75 interfaces for creating lightweight, 100% pure Java GUI components.

But in some ways, the hierarchy of the Swing component set has actually been simplified.

The following diagram shows just a small part of the Swing component hierarchy. But it also shows some important differences between the way class inheritance works in Swing and the way it works in the AWT component set.

UI classes and non-UI classes

In this diagram, two features of Swing are immediately apparent. All Swing component classes have names that start with "J," and all the component classes shown in the diagram descend from a class named JComponent.

Don't conclude from this diagram, however, that all Swing classes are "J" classes, or that all of them descend from JComponent. Swing has two kinds of classes -- UI classes and non-UI classes -- and only Swing's UI classes are "J" classes that descend from JComponent. Swing also has lots of non-UI classes that don't descend from JComponent and don't have names that begin with the letter J -- but we won't discuss any non-UI classes in this article. This article is about Swing components, so it focuses exclusively on Swing's UI classes.

And what's difference between UI classes and non-UI classes? The answer is that UI classes create visible components, such as buttons and menus, which applications can display on a monitor screen. Non-UI classes provide services for UI classes, and perform other kinds of vital operations, but don't have user interfaces and don't display anything on the screen.

Swing's event classes and model classes are examples of non-UI classes. You'll use many different kinds of non-UI classes when you start working with Swing.

Inheritance differences between AWT and Swing

The diagram presented above shows how a number of Swing's UI classes descend from the JComponent class. If you're familiar with AWT, it might appear at first glance that Swing components inherit from the JComponent class in just about the same way that AWT components used to inherit from the Component class in pre-Swing versions of AWT.

But if you refer back to the diagram again, and look at it very closely, you may notice some interesting differences between the way Swing components inherit from the JComponent class and the way AWT components used to inherit from the Component class.

Changes in button-component hierarchy

You can observe several major differences between Swing and AWT by examining the way in which button inheritance works in the two tool sets. In AWT, there are only two button classes -- the Button and CheckBox classes -- and both Button and CheckBox inherit directly from the Component class, like this:

In Swing, two new kinds of buttons have been added, and the button-component hierarchy tree has been rearranged. The Swing button hierarchy looks like this:

Notice that Swing has both a radio-button class and a check-box class. In pre-Swing versions of AWT, there was no radio-button class: the CheckBox class pulled double duty, serving as both a check-box class and a radio-button class. But Swing now has a real radio-button class (JRadioButton) as well as a check-box class (JCheckBox), making both kinds of buttons considerably easier to create and implement.

In Swing, both JRadioButton and JCheckBox descend from another new button class named JToggleButton^api, which has three states: pressed, enabled, and selected. (Actually, all buttons have these three states; however, JButton ignores the selected state.)

All of Swing's button classes -- JButton, JToggleButton, JRadioButton, and JCheckBox -- descend from an abstract class named AbstractButton^api, which neatly encapsulates their common features and capabilities. The AbstractButton class descends directly from the JComponent^api class.

Changes in menu-component hierarchy

There are many other differences between the Swing class hierarchy and the AWT class hierarchy, but we'll take a quick look at just one more class tree -- the menu tree -- before we move on to another topic.

You may know that in pre-Swing AWT, menu classes did not descend from the Component class, but from the AWT's Object class, in an arrangement that looked something like this:

In Swing, all menu classes do descend from JComponent, in a more complex tree that also encompasses the button tree that you saw in the preceding section:

Because the button and menu trees are linked together in this way in Swing, it's easier to coordinate button events and menu events in Swing than it was in pre-Swing versions of AWT.

In fact, Swing has a new interface -- called the Action interface -- that can listen for menu and button events at the same time. This means that in Swing, you can synchronize and coordinate menu events and button events in a way that was never possible in pre-Swing versions of AWT.

In a Swing program, for example, a single mouse click can activate or deactivate both a menu item and a corresponding toolbar button. You'll see exactly how that works in an article on Action events soon to be published in The Swing Connection.

Swing, like any well-behaved collection of Java software, groups its classes and interfaces into packages. Swing's packages, and their contents, are:

As noted previously, Swing's UI classes create components and controls that you can see on the screen, while Swing's non-UI classes provide vital services and functionalities to Swing's control classes and the applications that use them.

Some non-UI classes -- such as ButtonGroup^api and ImageIcon^api -- are defined in the Swing component package, along with Swing's component classes. But most of Swing's non-component classes are implemented in the other packages listed in the section titled "What's in the Swing packages " presented earlier this article.

JComponent^api, an abstract class, is the root class of almost of of Swing's user-interface ("J") components. JComponent's root class is the Object class, which is defined in the java.lang.Object file. JComponent also inherits from the AWT Container and Component classes, as shown in the following diagram. JComponent implements the Accessibility^api and Serializable interfaces.

What the JComponent class provides

Swing's UI components inherit the following features and capabilities from the JComponent class:

Look-and-feel implementations generally initialize a component's border property when the component is constructed. However, you can always override the initial value for the border property with your own custom border. The BorderFactory class provides a set of predefined borders that you can use.

JApplet is a new class used to create applets in Swing programs. Although JApplet^api is based on the old AWT Applet class, it is used a little differently. It provides input and painting mechanisms for its children -- something that the AWT Applet class did not do. It also provides other kinds of special support for applets with special requirements, such as applets that use the JLayeredPane class and the JMenuBar class.

One important characteristic of the JApplet class is that a JApplet object can have just one child: an object of a class named JRootPane.

^api. When you want to display a component inside an applet, you can't simply call the add() method to add the component to your applet; instead, must call a JRootPane method called getContentPane().

For now, you must use the swing.JApplet class instead of the applet.Applet when you want to create a Swing applet. If you don't, your applet will not repaint properly. For more details, see the JApplet entry in the "Component Gallery" article.

This section presents a table that lists and summarizes all visible UI ("J") classes that existed in Swing at press time. The table contains links that can take you to sources for more information about each component. Some brief comments about each class are also provided.

Summary of Swing's component classes