Skip to main content
Logo image

Java, Java, Java: Object-Oriented Problem Solving, 2024E

Section 13.2 Java Swing Library

Ever since the release of version 1.2 of the Java Development Kit (JDK) in 2000, Java has contained two distinct libraries of GUI components. The Abstract Windowing Toolkit (AWT) has been part of Java since the original 1.0 version of the JDK 1.0. The more advanced Java Swing library was first introduced in JDK 1.1 and was extensively revised in JDK 1.2. The Swing GUI components are part of the Java Foundation Classes (JFC), a collection of classes that do not depend as much on the underlying platform. The Swing library makes it possible to write GUI programs entirely in Java. Because they are rendered entirely by Java code, Swing components make it possible to design GUIs that are truly platform independent. Such programs are much more portable than those which rely on AWT components and the underlying platform. A program that uses Swing components will have the same look and feel on a Mac, Windows, or Unix platform. The library package javax.swing provides a set of lightweight (all-Java language) components that work the same on all platforms.

Subsection 13.2.1 Swing classes

Figures 13.2.1 and Figure 13.2.2 show the relationship between AWT and Swing classes. The top-level Swing classes—the JApplet, JDialog, JFrame, and JWindow—are direct subclasses of their corresponding AWT counterparts. These are the top-level GUI windows.
Figure 13.2.1. Swing classes, part 1: Relationship between the AWT and the top-level Swing windows. REVISION: JWindow extends Window.
The remaining Swing components ( Figure 13.2.2) are subclasses of java.awt.Component and java.awt.Container. As you can see, the names of Swing and AWT components are very similar. Swing components that have corresponding AWT components have names that begin with “J.”
Figure 13.2.2. Swing classes, part 2: Swing GUI components are derived from the JComponent class.
One might think that because Swing components are superior to their AWT counterparts, the AWT package will eventually be dropped. However, this is not likely. Even if a Java program uses Swing components exclusively, that will still not break the dependence on the AWT.
There are several reasons for this dependence. First, Swing’s top-level window classes—JApplet, JDialog, JFrame, and JWindow—are defined as extensions to their AWT counterparts. This means that Swing-based GUIs are still dependent on the AWT. Java programs need to have some way to map their windows to the windowing system used on the native (Windows, Unix, or Macintosh) platform. The AWT’s top-level windows—Window, Frame, Dialog, and Panel—provide that mapping.
Second, the JComponent class, which is the basis for all Swing components, is derived from java.awt.Container. There are many more such dependencies. Fundamentally, Swing components are based on the AWT.
Finally, all GUI applications and applets use layout managers (java.\-awt.FlowLayout), fonts (java.awt.Font), colors ( java.awt.Color), and other non-component classes that are defined in the AWT. There is just no way to design a GUI without using AWT classes. Therefore, the programs presented in this and subsequent chapters will use Swing components instead of corresponding AWT components, but they also will use layouts and other elements from the AWT.

Subsection 13.2.2 The Swing Component Set

Java’s Swing components are defined in a collection of packages named javax.swing.*, which is imported by the code shown in this and subsequent chapters. Swing packages include the following:
javax.swing.event.*
javax.swing.text.*
javax.swing.plaf.*
The javax.swing.event package defines the various Swing events and their listeners, such as the MenuEvent and the MenuListener. (In the AWT, the AWT events and listeners were defined in java.awt.event.)
The javax.swing.text package contains the classes for JTextField and JTextComponent. The Swing text components are more complex than their AWT counterparts. For example, one of their important features is the ability to undo changes made to the text they contain. This feature is crucial for building sophisticated word-processing applications.
The javax.swing.plaf package contains Swing’s look-and-feel classes. The term plaf is an acronym for pluggable look and feel. It refers to the fact that changing an application’s look and feel is a simple matter of “plugging in” a different plaf model. Changing how a program looks does not change what it does.
Swing’s platform-independent look and feel is achieved by placing all the code responsible for drawing a component in a class that is separate from the component itself. For example, in addition to JButton, the class that defines the button control, there will be a separate class responsible for drawing the button on the screen. The drawing class will control the button’s color, shape, and other characteristics of its appearance.
There are several look-and-feel packages built into Swing. For example, the javax.swing.plaf.motif package contains the classes that implement the Motif interface, a common Unix-based interface. The javax.swing.plaf.windows packages contains classes that support a Windows look and feel, and the javax.swing.plaf.metal package provides classes that support the Metal interface, a Java look and feel. These classes know how to draw each component and how to react to mouse, keyboard, and other events associated with these components.
You have attempted of activities on this page.