Subpages: 1. Chapter 1. Swing Overview. AWT, Swing
2. MVC architecture: Model, View, Controller
3. Custom models - II, UI delegates and PLAF
Part I - Foundations
Part I consists of two chapters that lay the foundation for a successful and productive journey through the JFC Swing class library. The first begins with a brief overview of what Swing is and an introduction to its architecture. The second builds up into a detailed discussion of the key mechanisms underlying Swing, and how to interact with them. There are several sections on topics that are fairly advanced, such as multithreading and painting. This material is central to many areas of Swing and by introducing it in chapter 2, your understanding of what is to come will be significantly enhanced. We expect that you will want to refer back to this chapter quite often, and in several places we explicitly refer you to it in the text. At the very least, it is recommended that you know what chapter 2 contains before moving on.
Chapter 1. Swing Overview
In this chapter:
- UI delegates and PLAF
AWT (the Abstract Window Toolkit) is the part of Java designed for creating user interfaces and painting graphics and images. It is a set of classes intended to provide everything a developer requires in order to create a graphical interface for any Java applet or application. Most AWT components are derived from the java.awt.Component class as figure 1.1 illustrates. (Note that AWT menu bars and menu bar items do not fit within the Component hierarchy.)
Figure 1.1 Partial Component hierarchy
The Java Foundation Classes consist of five major parts: AWT, Swing, Accessibility, Java 2D, and Drag and Drop. Java 2D has become an integral part of AWT, Swing is built on top of AWT, and Accessibility support is built into Swing. The five parts of JFC are certainly not mutually exclusive, and Swing is expected to merge more deeply with AWT in future versions of Java. The Drag and Drop API was far from mature at the time of this writing but we expect this technology to integrate further with Swing and AWT in the near future. Thus, AWT is at the core of JFC, which in turn makes it one of the most important libraries in Java 2.
Swing is a large set of components ranging from the very simple, such as labels, to the very complex, such as tables, trees, and styled text documents. Almost all Swing components are derived from a single parent called JComponent which extends the AWT Container class. Thus, Swing is best described as a layer on top of AWT rather than a replacement for it. Figure 1.2 shows a partial JComponent hierarchy. If you compare this with the AWT Component heirarchy of figure 1.1 you will notice that for each AWT component there is a Swing equivalent with prefix "J". The only exception to this is the AWT Canvas class, for which JComponent, JLabel, or JPanel can be used as a replacement (in section 2.8 we discuss this in detail). You will also notice many Swing classes with no AWT counterparts.
Figure 1.2 represents only a small fraction of the Swing library, but this fraction consists of the classes you will be dealing with most. The rest of Swing exists to provide extensive support and customization capabilities for the components these classes define.
Figure 1.2 Partial JComponent hierarchy
Swing components are referred to as lightweights while AWT components are referred to as heavyweights. The difference between lightweight and heavyweight components is z-order: the notion of depth or layering. Each heavyweight component occupies its own z-order layer. All lightweight components are contained inside heavyweight components and maintain their own layering scheme defined by Swing. When we place a heavyweight inside another heavyweight container it will, by definition, overlap all lightweights in that container.
What this ultimately means is that we should avoid using both heavyweight and lightweight components in the same container whenever possible. This does not mean that we can never mix AWT and Swing components successfully. It just means we have to be careful and know which situations are safe and which are not. Since we probably won't be able to completely eliminate the use of heavyweight components anytime soon, we have to find ways to make the two technologies work together in an acceptable way.
The most important rule to follow is that we should never place heavyweight components inside lightweight containers that commonly support overlapping children. Some examples of these containers are JInternalFrame, JScrollPane, JLayeredPane, and JDesktopPane. Secondly, if we use a popup menu in a container holding a heavyweight component, we need to force that popup to be heavyweight. To control this for a specific JPopupMenu instance we can use its setLightWeightPopupEnabled() method.
Alternatively we can call JPopupMenu's static setDefaultLightWeightPopupEnabled() method, and pass it a value of false to force all popups in a Java session to be heavyweight. Note that this will only affect popup menus created after this call is made. It is therefore a good idea to call this method early within initialization.
1.2.2 Platform independence
The most remarkable thing about Swing components is that they are written in 100% Java and do not depend on peer components, as most AWT components do. This means that a Swing button or text area will look and function identically on Macintosh, Solaris, Linux, and Windows platforms. This design eliminates the need to test and debug applications on each target platform.
1.2.3 Swing package overview
Contains the most basic Swing components, default component models, and interfaces. (Most of the classes shown in Figure 1.2 are contained in this package.)
Classes and interfaces used to define specific border styles. Note that borders can be shared by any number of Swing components, as they are not components themselves.
Classes and interfaces supporting the JColorChooser component, used for color selection. (This package also contains some interesting undocumented private classes.)
The event package contains all Swing-specific event types and listeners. Swing components also support events and listeners defined in java.awt.event and java.beans.
Classes and interfaces supporting the JFileChooser component, used for file selection.
Contains the pluggable look-and-feel API used to define custom user interface components. Most of the classes in this package are abstract. They are subclassed and implemented by look-and-feel implementations such as metal, motif, and basic. The classes in this package are intended for use only by developers who, for one reason or another, cannot build on top of existing look-and-feels.
Consists of the Basic look-and-feel implementation which all look-and-feels provided with Swing are built on top of. We are normally expected to subclass the classes in this package if we want to create our own customized look-and-feel.
Metal is the default look-and-feel of Swing components. It is the only look-and-feel that ships with Swing not designed to be consistent with a specific platform.
This is the Multiplexing look-and-feel. This is not a regular look-and-feel implementation in that it does not define the actual look or feel of any components. Rather, it provides the ability to combine several look-and-feels for simultanteous use. A typical example might be using an audio-based look-and-feel in combination with metal or motif. Currently Java 2 does not ship with any multiplexing look-and-feel implemenations (however, rumor has it that the Swing team is working on an audio look-and-feel as we write this).
Classes and interfaces supporting the JTable control. This component is used to manage tabular data in spreadsheet form. It supports a high degree of customization without requiring look-and-feel enhancements.
Classes and interfaces used by the text components including support for plain and styled documents, the views of those documents, highlighting, caret control and customization, editor actions and keyboard customization.
This extension of the text package contains support for HTML text components. (HTML support was being completely rewritten and expanded upon while we were writing this book. Because of this our coverage of it is regretably limited.)
Support for parsing HTML.
Contains support for RTF documents.
Classes and interfaces supporting the JTree component. This component is used for the display and management of hierarcical data. It supports a high degree of customization without requiring look-and-feel enhancements.
The undo package contains support for implementing and managing undo/redo functionality.