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 the JFC) was fully
integrated into Java.
Swing Is Built on the AWT
Before moving on, it is necessary to make one important point: although Swing eliminates
a number of the limitations inherent in the AWT, Swing does not replace it. Instead, Swing
is built on the foundation of the AWT. This is why the AWT is still a crucial part of Java.
Swing also uses the same event handling mechanism as the AWT. Therefore, a basic
understanding of the AWT and of event handling is required to use Swing. (The AWT
is covered in Chapters 23 and 24. Event handling is described in Chapter 22.)
Two Key Swing Features
As just explained, Swing was created to address the limitations present in the AWT. It does
this through two key features: lightweight components and a pluggable look and feel.
Together they provide an elegant, yet easy-to-use solution to the problems of the AWT.
More than anything else, it is these two features that define the essence of Swing. Each
is examined here.
Swing Components Are Lightweight
With very few exceptions, Swing components are lightweight. This means that they are written
entirely in Java and do not map directly to platform-specific peers. Because lightweight
components are rendered using graphics primitives, they can be transparent, which enables
nonrectangular shapes. Thus, lightweight components are more efficient and more flexible.
Furthermore, because lightweight components do not translate into native peers, the look and
feel of each component is determined by Swing, not by the underlying operating system. This
means that each component will work in a consistent manner across all platforms.
Swing Supports a Pluggable Look and Feel
Swing supports a pluggable look and feel (PLAF). Because each Swing component is rendered
by Java code rather than by native peers, the look and feel of a component is under the
control of Swing. This fact means that 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. Moreover, it becomes possible to define
entire sets of look-and-feels that represent different GUI styles. To use a specific style, its
look and feel is simply "plugged in." Once this is done, all components are automatically
rendered using that style.
Pluggable look-and-feels offer several important advantages. It is possible to define a
look and feel that is consistent across all platforms. Conversely, it is possible to create a look
Search WWH :
