Title

The Swing component set is a new graphical user-interface (GUI) toolkit that simplifies and streamlines the development of windowing components -- that is, the visual components (such as menus, tool bars, dialogs and the like) that are used in graphically based programs.

With Swing, you can develop powerful and scalable GUIs that have precisely the "look and feel" that you specify. That means that when you write a program using Swing components, a user can execute your program without modification on any kind of computer, and it will always look and feel just like a program written specifically for the particular computer on which it is running.

Furthermore, Swing components are said to be lightweight because they don't rely on user-interface code that's native to whatever operating system they're running on. Consequently, they can usually be implemented using less code than earlier "heavyweight" components require. (For more details on this topic, see the section on "Lightweight and heavyweight components" later in this article.)

A New Era of GUIs

When you create such a program and run it under Windows, it has the appearance and behavior of a program written specifically for Windows. When you run the same program on a UNIX workstation, it runs just like any program written for UNIX. When you run it on an Apple Macintosh, it looks and behaves just like any program written specifically for the Mac -- and so on.

There are also other ways to use Swing's PL&F capabilities. For example, Swing comes with a special cross-platform look and feel, named the Java look and feel, that always presents a set of components with the same appearance and behavior, no matter what operating system it is running on.

Finally, developers can create their own custom Swing components -- or complete sets of custom Swing components -- with any kind of look and feel they want to design.

This article introduces the Swing component set and shows how Swing components differ from their pre-Swing AWT predecessors. For a collective look at all the user-interface components in the Swing set, see the "Component Gallery" article. For more details about the classes, interfaces, and methods used in Swing, see the article titled "The Swing Tool Set." To learn more about the overall architecture of Swing components, see "An Overview of Swing Architecture."

Lightweight and Heavyweight Components

The Swing toolkit breaks new ground in GUI (graphical user interface) toolkit design because it is the first GUI toolkit for the Java^TM programming language that lets developers create lightweight components with a pluggable look-and-feel design.

Because many "heavyweight" components are used in programs that were written before Swing was introduced, the creators of Swing have made it possible to mix heavyweight and lightweight components in the same program. To learn how to do that, see the article titled "Mixing Heavy and Light Components" in The Swing Connection archive.

(For more details about peer code, lightweight components, and components in general, see the latest editions of The Java Tutorial.)

From an architectural standpoint, the Swing component set extends -- but does not replace -- the Abstract Windowing Toolkit (AWT) that is familiar to users of the the Java^TM programming language.

AWT, like Swing, is a set of object-oriented classes designed to help programmers write graphical user interfaces, or GUIs, for their Java programs.

Swing components are lightweight, just like the AWT components that made their debut along with the release of JDK 1.1. But the Swing set contains far more components than the pre-Swing AWT toolkit did, and Swing components have many new features and capabilities that old-style AWT components did not have. For example, all Swing UI components are designed using the pluggable look-and-feel (PL&F) architecture described in the article titled "An Overview of Swing Architecture." You'll learn about many other new features of Swing components as you read The Swing Connection.

By offering all these new features, Swing significantly extends and expands the power and versatility of the pre-Swing AWT toolkit. More specifically, Swing extends the Lightweight UI Framework that became part of the Java AWT with the introduction of JDK 1.1.

Many of the components in the Swing set are 100% Pure Java^TM versions of pre-Swing AWT components, such as Button, ScrollBar, List, and so on. But Swing also includes a Pure Java set of higher-level components (such as tree-view, list-box, and tabbed-pane components) that were not available in the pre-Swing AWT API.

Swing components, like AWT components, adhere to the specification that describes JavaBeans. Because JavaBean support is built into the Swing tool set, Swing components can be easily used in application-builder programs that make use of JavaBeans.

The Swing 1.0 tool set is implemented in Version 1.1 of the Java^TM Foundation Classes (JFC), a class library that is designed to help developers to build full-featured enterprise-ready applications. Along with the Swing component set, JFC contains three major APIs:

Java 2D, a set of classes for advanced 2D graphics and imaging. Java 2D supplies Java applications with many different paint styles, mechanisms for defining complex shapes, and classes and methods for fine-tuning the rendering process.
Drag and Drop, a technology that enables data transfer across Java and native applications, across Java applications, and within a single Java application. The JFC drag and drop specification is available on the java.sun.com web site.
The Accessibility API, an interface that provides assistive technologies such as screen magnifiers and audible text readers. These technologies are designed to help people with disabilities interact and communicate more easily and efficiently with JFC and AWT components.

These three APIs are examined more closely in the article titled "The Swing Tool Set."

Swing Architecture

As noted at the beginning of this article, Swing is an extension of the Abstract Windowing Toolkit (AWT). Architecturally, in fact, Swing sits atop part (but not all) of the AWT tool set, as shown in the following diagram.

The diagram shows how Swing sits on top of a number of the APIs that implement the various parts of JFC -- including the Java 2D and Drag and Drop APIs. Although both those APIs are part of JFC, they are not part of Swing. That's because certain tasks that they perform require use of native code. And Swing components, as we have seen, never rely on peer code. So Java 2D and Drag-and-Drop appear beneath, not inside, the rectangle labeled "Swing" in the diagram. So does the old-style AWT component set, which is extended (but not replaced) by Swing.

This doesn't mean that you can't use pre-Swing APIs in your applications. They are all still there, and you can use them if you like. In most cases, though, you'll probably want to use Swing components, because there are more of them and they offer a host of features and capabilities that you won't find in older AWT components. The features and capabilities of Swing components are what this document set is all about, so to find out more about them, just read on.

You can learn much more about the overall architecture of Swing components by reading the article titled "An Overview of Swing Architecture" that appears in this issue.

One of the most important differences between Swing and the pre-Swing AWT toolkit is that Swing components don't borrow any native code from the platforms on which they run. In other words, Swing does not use any platform-specific implementations (which AWT programmers used to refer to as "peers.") Instead, Swing creates its components using pluggable look-and-feel (PL&F, or plaf) modules that are written from scratch and don't use any native code at all.

By default, Swing automatically plugs in the L&F module that matches the platform you're running on, but because of Swing's pluggable-L&F capabilities, you can also set up other L&F modules to run in your GUI. Most of the L&F modules can be plugged in regardless of what platform you're running on. But a few of the platform L&F modules (currently Windows and, coming soon, Mac) can be run only on the platform they represent -- currently, Windows on Windows 95 and Windows NT, and (coming soon) a Mac L&F for the Macintosh.

If you like, you can even design your own pluggable L&F modules and use those in your application, no matter what platform your program is running on. (Creating customized L&Fs is the subject of a major article that will appear in the next issue of The Swing Connection.)

You can even change look and feel of your application's Swing components dynamically, at runtime, while your program is being executed!

None of this would be possible if Swing used native code supplied by the user's operating system, as earlier "heavyweight" components did. The preceding diagram shows how careful the creators of Swing were to free Swing completely from the restrictions of using peer code.

As the picture shows, the Java 2D, accessibility, and Drag and Drop APIs are part of JFC and are also part of AWT, but are not part of Swing. That's because the tasks that these three APIs perform force them to make use of native code. But Swing, as we have noted, never uses native code.

Consequently, the designers of Swing just said "no" to including the Java 2D, accessibility, and Drag and Drop APIs within the Swing tool set. Additionally, to ensure that Swing runs cleanly in a JDK 1.1 environment, the first release of the Swing components do not take advantage of the Java 2D or Drag and Drop APIs.

Of course, you can use these APIs in your Swing program if it will be running in a 1.2 environment (and that's why they're in the diagram). Real Swing integration with these new APIs is planned for a future release.

Swing, like Gaul, is divided into three parts. In fact, Swing is implemented using three main elements that are now part of JFC:

A brand-new set of components descended from a new component named JComponent^api. JComponent, descended from AWT's Container class, is the root class of almost all Swing component classes. This hierarchy allows Swing components -- even components such as Swing's label component, JLabel -- to contain other components. This arrangement makes Swing a very versatile tool set from the point of view of component nesting.
A group of Swing-related support classes. These classes do not create visible Swing components that appear on the computer screen, but do provide vital services to the Swing API and to your Swing applications.
A new set of Swing-related interfaces that are implemented by Swing's component classes and support classes.

All three of these Swing elements are described in much more detail in the article titled "The Swing Tool Set."

Swing and IFC

The Swing design team, working closely with a peer engineering team from Netscape, created Swing by incorporating the best features of both the AWT and Netscape's IFC (Internet Foundation Class) library.

Because Swing was developed in cooperation with engineers from Netscape, in its infancy it bore a close resemblance to Netscape's Internet Foundation Class class library (IFC). But that resemblance vanished quickly, and from the the point of view of the developer, Swing now bears little resemblance to IFC.

If you have developed programs with IFC, you might notice some similarities in the default look and feel of Swing and IFC widgets, because parts of Swing's rendering mechanisms are descended from IFC. You might be able to pick out some other commonalties as well, but not many -- especially since newly designed pluggable L&Fs are now giving Swing components different looks and feels in different implementations.