Java Swing, 2nd Edition

What Is Swing?

If you poke around the Java home page ( g), you’ll find Swing described as a set of customizable graphical components whose look-and-feel (L&F) can be dictated at runtime. In reality, however, Swing is much more than this. Swing is the next-generation GUI toolkit that Sun Microsystems created to enable enterprise development in Java. By enterprise development , we mean that programmers can use Swing to create large-scale Java applications with a wide array of powerful components. In addition, you can easily extend or modify these components to control their appearance and behavior.

Swing is not an acronym. The name represents the collaborative choice of its designers when the project was kicked off in late 1996. Swing is actually part of a larger family of Java products known as the Java Foundation Classes ( JFC), which incorporate many of the features of Netscape’s Internet Foundation Classes (IFC) as well as design aspects from IBM’s Taligent division and Lighthouse Design. Swing has been in active development since the beta period of the Java Development Kit ( JDK) 1.1, circa spring of 1997. The Swing APIs entered beta in the latter half of 1997 and were initially released in March 1998. When released, the Swing 1.0 libraries contained nearly 250 classes and 80 interfaces. Growth has continued since then: at press time, Swing 1.4 contains 85 public interfaces and 451 public classes.

Although Swing was developed separately from the core Java Development Kit, it does require at least JDK 1.1.5 to run. Swing builds on the event model introduced in the 1.1 series of JDKs; you cannot use the Swing libraries with the older JDK 1.0.2. In addition, you must have a Java 1.1-enabled browser to support Swing applets. The Java 2 SDK 1.4 release includes many updated Swing classes and a few new features. Swing is fully integrated into both the developer’s kit and the runtime environment of all Java 2 releases (SDK 1.2 and higher), including the Java Plug-In.

What Are the Java Foundation Classes?

The FC is a suite of libraries designed to assist programmers in creating enterprise applications with Java. The Swing API is only one of five libraries that make up the JFC. The JFC also consists of the Abstract Window Toolkit (AWT), the Accessibility API, the 2D API, and enhanced support for Drag and Drop capabilities. While the Swing API is the primary focus of this book, here is a brief introduction to the other elements in the JFC:

AWT

The Abstract Window Toolkit is the basic GUI toolkit shipped with all versions of the Java Development Kit. While Swing does not reuse any of the older AWT components, it does build on the lightweight component facilities introduced in AWT 1.1.

Accessibility

The accessibility package provides assistance to users who have trouble with traditional user interfaces. Accessibility tools can be used in conjunction with devices such as audible text readers or braille keyboards to allow direct access to the Swing components. Accessibility is split into two parts: the Accessibility API, which is shipped with the Swing distribution, and the Accessibility Utilities API, which is distributed separately. All Swing components support accessibility, so this book dedicates an entire chapter (Chapter 25) to accessibility design and use.

2D API

The 2D API contains classes for implementing various painting styles, complex shapes, fonts, and colors. This Java package is loosely based on APIs that were licensed from IBM’s Taligent division. The 2D API classes are not part of Swing, so they are not covered in this book.

Drag and Drop

Drag and Drop (DnD) is one of the more common metaphors used in graphical interfaces today. The user is allowed to click and “hold” a GUI object, moving it to another window or frame in the desktop with predictable results. The DnD API allows users to implement droppable elements that transfer information between Java applications and native applications. Although DnD is not part of Swing, it is crucial to a commercial-quality application. We tackle this topic in Chapter 24.

Figure 1-1 enumerates the various components of the Java Foundation Classes. Because part of the Accessibility API is shipped with the Swing distribution, we show it overlapping Swing.

Figure 1-1. The five APIs of the JFC

Is Swing a Replacement for AWT?

No. Swing is actually built on top of the core AWT libraries. Because Swing does not contain any platform-specific (native) code, you can deploy the Swing distribution on any platform that implements the Java 1.1.5 or above virtual machine. In fact, if you have JDK 1.2 or higher on your platform, then the Swing classes are already available, and there’s nothing further to download. If you use a JDK version prior to 1.2, you can download the entire set of Swing libraries as a set of Java Archive (JAR) files from the Swing home page, http://java.sun.com/products/jfc. In either case, it is generally a good idea to visit this URL for any extra packages or L&Fs that may be distributed separately from the core Swing libraries.

Figure 1-2 shows the relationship between Swing, AWT, and the Java Development Kit in the 1.1 and higher JDKs. In JDK 1.1, the Swing classes must be downloaded separately and included as an archive file on the classpath (swingall.jar).^[1] JDK 1.2 (and higher) comes with a Swing distribution.

Figure 1-2. Relationships between Swing, AWT, and the JDK in the 1.1 and higher SDKs

Swing contains many more graphical components than its immediate predecessor, AWT 1.1. Many are components that were scribbled on programmer wishlists since Java first debuted—including tables, trees, internal frames, and a plethora of advanced text components. In addition, Swing contains many design advances over AWT. For example, Swing introduced an Action class that makes it easier to coordinate GUI components with their functionality. You’ll also find that a much cleaner design prevails throughout Swing; this cuts down on the number of unexpected surprises that you’re likely to face while coding.

Swing depends extensively on the event-handling mechanism of AWT 1.1, although it does not define a comparatively large amount of events for itself. Each Swing component also contains a variable number of exportable properties. This combination of properties and events in the design was no accident. Each of the Swing components, like the AWT 1.1 components before them, adhere to the popular JavaBeans specification. As you might have guessed, this means that you can import all of the Swing components into various GUI builder tools, which is useful for powerful visual programming.

Rethinking the AWT

To understand why Swing exists, it helps to understand the market forces that drive Java as a whole. The Java Programming Language was developed in 1993 and 1994, largely under the guidance of James Gosling and Bill Joy at Sun Microsystems, Inc. When Sun released the Java Development Kit on the Internet, it ignited a firestorm of excitement that swept through the computing industry. At first, developers primarily experimented with Java for applets , mini-programs embedded in web browsers. However, as Java matured over the course of the next two years, many developers began using Java to develop full-scale applications.

Or at least they tried. As developers ported Java to more and more platforms, its weak points started to show. The language was robust and scalable, extremely powerful as a networking tool, and served well as an easy-to-learn successor to the more established C++. The primary criticism, however, was that it was an interpreted language, which means that by definition it executed code slower than its native, compiled equivalents. Consequently, many developers flocked to just-in-time (JIT) compilers—highly optimized interpreters—to speed up their large-scale applications. This solved many problems, but one weak point that continually received scathing criticism was the graphical widgets that Java was built on: the Abstract Window Toolkit (AWT). The primary issue here was that AWT provided only the minimal amount of functionality necessary to create a windowing application. For enterprise applications, it quickly became clear that programmers needed something bigger.

After nearly a year of intense scrutiny, the AWT classes were ready for a change. From Java 1.0 to Java 1.1, the AWT reimplemented its event model from a “chain” design to an “event subscriber” design. This meant that instead of propagating events through a predefined hierarchy of components, interested classes simply registered with other components to receive noteworthy events. Because events typically involve only the sender and receiver, this eliminated much of the overhead in propagating them. When component events were triggered, an event object was passed only to those classes interested in receiving them.

Sun developers also began to see that relying on native widgets for the AWT components was proving to be troublesome. Similar components looked and behaved differently on many platforms, and coding for the ever-expanding differences of each platform became a maintenance nightmare. In addition, reusing the component widgets for each platform limited the abilities of the components and proved to be expensive on system memory.

Clearly, Sun knew that AWT wasn’t enough. It wasn’t that the AWT classes didn’t work; they simply didn’t provide the functionality necessary for full-scale enterprise applications. At the 1997 JavaOne Conference in San Francisco, JavaSoft announced the Java Foundation Classes. Key to the design of the JFC was that the new Swing components would be written entirely in Java and have a consistent L&F across platforms. This allowed Swing and the JFC to be used on any platform that supported Java 1.1 or later; all the user had to do was to include the appropriate JAR files on the CLASSPATH to make each of the components available for use. Since JDK 1.2, Swing has been part of the standard Java distribution; no special action is needed to use Swing components.

---

^[1] The standalone Swing distributions contain several other JAR files. swingall.jar is everything (except the contents of multi.jar) wrapped into one lump and is all you normally need to know about. For completeness, the other JAR files are: swing.jar, which contains everything but the individual L&F packages; motif.jar, which contains the Motif (Unix) L&F; windows.jar, which contains the Windows L&F; multi.jar, which contains a special L&F that allows additional (often nonvisual) L&Fss to be used in conjunction with the primary L&F; and beaninfo.jar, which contains special classes used by GUI development tools.