System, but they may not be reproduced for publication

NOTE
For a comprehensive introduction to Swing, see my book Swing: A Beginner’s Guide
(McGraw­Hill Professional, 2007).
THE ORIGINS AND DESIGN PHILOSOPHY OF

---

THE ORIGINS AND DESIGN PHILOSOPHY OF
SWING
Swing did not exist in the early days of Java. Rather, it was a response to deficiencies
present in Java’s original GUI subsystem: the Abstract Window Toolkit (AWT). The
AWT defines a basic set of components that support a usable, but limited, graphical
interface. One reason for the limited nature of the AWT is that it translates its various
visual components into their corresponding, platform­specific equivalents, or peers.
This means that the look and feel of an AWT component is defined by the platform, not
by Java. Because the AWT components use native code resources, they are referred to
as heavyweight.
The use of native peers led to several problems. First, because of differences between
operating systems, a component might look, or even act, differently on different
platforms. This potential variability threatened the overarching philosophy of Java:
write once, run anywhere. Second, the look and feel of each component was fixed
(because it is defined by the platform) and could not be (easily) changed. Third, the use
of heavyweight components caused some frustrating restrictions. For example, a
heavyweight component was always opaque.
Not long after Java’s original release, it became apparent that the limitations and
restrictions present in the AWT were sufficiently serious that a better approach was
needed. The solution was Swing. Introduced in 1997, Swing was included as part of the
Java Foundation Classes (JFC). Swing was initially available for use with Java 1.1 as a
separate library. However, beginning with Java 1.2, Swing (and the rest of JFC) was
fully integrated into Java.
Swing addresses the limitations associated with the AWT’s components through the use
of two key features: lightweight components and a pluggable look and feel. Although
they are largely transparent to the programmer, these two features are at the
foundation of Swing’s design philosophy and the reason for much of its power and
flexibility. Let’s look at each.
With very few exceptions, Swing components are lightweight. This means that a
component is written entirely in Java. They do not rely on platform­specific peers.
Lightweight components have some important advantages, including efficiency and
flexibility. Furthermore, because lightweight components do not translate into
platform­specific peers, the look and feel of each component is determined by Swing,
not by the underlying operating system. This means that each component can work in a
consistent manner across all platforms.

---

Because each Swing component is rendered by Java code rather than by platform­
specific peers, it is possible to separate the look and feel of a component from the logic
of the component, and this is what Swing does. Separating out the look and feel
provides a significant advantage: it becomes possible to change the way that a
component is rendered without affecting any of its other aspects. In other words, it is
possible to “plug in” a new look and feel for any given component without creating any
side effects in the code that uses that component.
Java provides look­and­feels, such as metal and Nimbus, that are available to all Swing
users. The metal look and feel is also called the Java look and feel. It is a platform­
independent look and feel that is available in all Java execution environments. It is also
the default look and feel. For this reason, the default Java look and feel (metal) is used
by the examples in this chapter.
Swing’s pluggable look and feel is made possible because Swing uses a modified version
of the classic model­view­controller (MVC) architecture. In MVC terminology, the