In Win32, the term control means the group of all the GUI things that users can press, scroll, choose between, type into, draw on, and so forth. In the Unix XWindows world, a control is called a widget.

Control and widget are not Java terms. Instead, we use the term component, or, when talking specifically about Swing, the JComponent subclass of Component. Each Swing control is a subclass of javax.swing.JComponent, so each control inherits all the methods and data fields of JComponent. JComponents are serializable, meaning the object can be written out to disk, can be read in again later, and can become an object again. They follow the rules for JavaBeans, so they can be coupled together in visual builder tools.

This chapter is about explaining the Swing components and how you use them. You will build up your GUI programs using these components. The first thing to note is that the Swing components are no longer peer-based, but are written in Java and are thus consistent on all platforms. Under the AWT, a button ended up being a Win32 button on Windows, a Macintosh button on the Macintosh, and a Motif button on Unix. With Swing, the button is rendered on a little bit of screen area that belongs to some ancestor Java component, and Swing puts all the button semantics on top of that. Swing draws the button so it looks armed (ready to push), pushed, or disabled. Because the code is written in Java, the button has identical behavior no matter where it runs.

JFC is quite a big topic. There are more than three hundred classes in the Swing library alone. We'll present nine or 10 individual Swing JComponents here, and provide pointers on the rest. This amounts to several pages, so I recommend you read one or two in depth, then just look at the figures to get an idea of what each does. Return to the appropriate section in the chapter as you need actual code examples.

Object-oriented programming fits well with window systems. The concept of making new controls by subclassing existing ones and overriding part of their behavior saves time and effort. Another similarity is the way that controls have to handle events just as objects handle messages. (Method calls are equivalent to sending a message to an object, and some OOP languages refer to making a method call as “sending a message”).

There is an abstract class called JComponent, which is the parent class for most things that can appear on screen. The basic ingredients of a GUI are all subclasses of the class called JComponent. JComponent is the superclass that holds the common information about an onscreen control and provides higher-level features common to each control, as shown in the following list:

Components correspond to “things that interact with the user” and containers are “backdrops to put them on”. The superclass of javax.swing.JComponent is java.awt.Container. The parent of container is the java.awt component.

The behavior and appearance of each specific control is one level down in the subclasses of JComponent. The Swing lightweight controls can be divided as shown in Table 21-1. We will look at just one or two components from each of these categories.

Each control has methods appropriate to what it does. The JFileChooser control has methods to get and set the current directory, get the selected filename(s), apply a file name filter, and so on. We'll examine these individual JComponents later in the chapter.