Java Reference
In-Depth Information
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 compon-
ents 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 restric-
tions 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 Founda-
tion 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 com-
ponent is written entirely in Java. They do not rely on platform-specific peers. Lightweight
components have some important advantages, including efficiency and flexibility. Further-
more, 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 plat-
forms.
Because each Swing component is rendered by Java code rather than by platform-spe-
cific 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
Search WWH ::




Custom Search