Swing Packages and Classes

Swing Packages

Here is a short description of each package in the Swing libraries.


Contains classes and interfaces that can be used to allow assistive technologies to interact with Swing components. Assistive technologies cover a broad range of items, from audible text readers to screen magnification. Although the accessibility classes are technically not part of Swing, they are used extensively throughout the Swing components. We discuss the accessibility package in greater detail in Chapter 25.


Contains the core Swing components, including most of the model interfaces and support classes.


Contains the definitions for the abstract border class as well as eight predefined borders. Borders are not components; instead, they are special graphical elements that Swing treats as properties and places around components in place of their insets. If you wish to create your own border, you can subclass one of the existing borders in this package, or you can code a new one from scratch.


Contains support for the JColorChooser component, discussed in Chapter 12.


Defines several new listeners and events that Swing components use to communicate asynchronous information between classes. To create your own events, you can subclass various events in this package or write your own event class.


Contains support for the JFileChooser component, discussed in Chapter 12.


Contains an assortment of components that aren’t ready for prime time, but may be in the future. Play here at your own risk. The contents of the pending package aren’t discussed in this book.


Defines the unique elements that make up the pluggable look-and-feel for each Swing component. Its various subpackages are devoted to rendering the individual look-and-feels for each component on a platform-by-platform basis. (Concrete implementations of the Windows and Motif L&Fs are in subpackages of com.sun.java.swing.plaf.)


Provides models and views for the table component. The table component allows you to arrange various information in a grid-based format with an appearance similar to a spreadsheet. Using the lower-level classes, you can manipulate how tables are viewed and selected, as well as how they display their information in each cell.


Provides scores of text-based classes and interfaces supporting a common design known as document/view . The text classes are among the more advanced Swing classes to learn, so we will devote several chapters (19-24) to both the design fundamentals and the implementation of several text applications.


Used specifically for reading and formatting HTML text through an ancillary editor kit.


Contains support for parsing HTML.


Used specifically for reading and formatting the Rich Text Format (RTF) text through an ancillary editor kit.


Defines models and views for a hierarchal tree component, such as you might see representing a file structure or a series of properties.


Contains the necessary functionality for implementing undoable functions.

By far the most widely-used package is javax.swing. In fact, almost all the Swing components, as well as several utility classes, are located inside this package. The only exceptions are borders and support classes for the trees, tables, and text-based components. Because the latter components are much more extensible and often have many more classes to work with, these classes have been broken off into separate packages.

Class Hierarchy

Figure 1.4 shows a detailed overview of the Swing class hierarchy as it appears in the 1.2 JDK. At first glance, the class hierarchy looks very similar to AWT. Each Swing component with an AWT equivalent shares the same name, except that the Swing class is preceded by a capital “J”. In most cases, if a Swing component supersedes an AWT component, it can be used as a drop-in replacement.

The Swing component hierarchy

Figure 1-4. The Swing component hierarchy

Upon closer inspection, however, you will discover that there are welcome differences between the Swing and AWT components. The first item that you might notice is that the menu components, including JMenuBar, are now descendants of the same base component as the others: JComponent. This is a change from the older AWT menu classes. Both the AWT 1.0 and 1.1 menu classes inherited their own high-level component, MenuComponent, which severely limited their capabilities. In addition, this design prevented menubars from being positioned with layout managers inside containers; instead, Java simply attached menubars to the top of frames.

Also, note that Swing has redesigned the button hierarchy. It now includes a JToggleButton class, which is used in dual-state components. For example, if you click on a toggle button while in the “released” position, the button switches to the “pressed” state and remains in that state. When it is clicked again, the button returns to the released state. Note that the JToggleButton outlines behavior seen in radio buttons and checkboxes. Hence, these classes inherit from JToggleButton in the new Swing design. Also, note the addition of the JRadioButton and JRadioButtonMenuItem classes in Swing. Until now, Java forced developers to use the AWT checkbox-equivalent to mimic radio buttons.

You might have noticed an increase in the number of “frames” and “panes” in Swing. For example, consider internal frames . Swing can now support placing frames inside other frames—this is commonly referred to as an MDI (multiple document interface) in the Microsoft Windows world. You can assign these internal frames arbitrary vertical layers; these layers determine which internal frame will appear on top. In fact, even the simplest frame, JFrame, embraces the concept of layers by including support for layered panes on which you can position different elements of your application. These topics are discussed in more detail in Chapter 9, and Chapter 11.

There are many other design enhancements in Swing; too many, in fact, to discuss here. However, before we go on, we should discuss one of the fundamental designs behind every Swing component: the model-view-controller architecture .

[5] At one point, Sun intended to package Swing and Accessibility under the java.awt hierarchy. In this system, com.sun.java.accessibility would be java.awt.accessibility . The beta 2 and beta 3 releases of JDK 1.2 reflect the java.awt packaging. Sun reverted to com.sun.java for beta 4, and is using the javax.swing hierarchy for the actual release of JDK 1.2. Sun provides a free tool for automatically adjusting the package names in any code you’ve written for earlier releases. For more information, see http://java.sun.com/products/jfc/PackageRenamer/.

Get Java Swing now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.