Java Reference
In-Depth Information
like draw them on-screen. The decision to base the AWT architecture around peers had some important
consequences, and development efforts must usually take these into account:
Benefits
There is less code to write in the API, since the underlying platform does most of the work.
GUIs look and behave as they would on the operating system on which they are run.
Drawbacks
If you want to support true platform independence, you must consider the least common denominator when
providing components. This means that AWT GUIs are not as feature-rich as they could have been with other
approaches.
If there are any quirks in the graphical components of an operating system, the AWT application inherits those
along with the functionality.
Since peers have to be used for many operations of the GUI components, they can potentially slow down an
application and present scaling issues.
Because of the drawbacks of the peer components, it might be better for developers to directly extend one of the
two base classes of the model:
Component
or
Container
. Since neither of these classes has native platform peers,
any direct subclass of them would inherit the core functionality of AWT without suffering from the limitations of
the peer architecture. Naturally, this comes at a price—developers have to write the code to draw components
from scratch.
The Swing Architectural Model
The entire Swing architecture is based on the concept of extending functionality from the AWT Container class.
This includes the vast majority of graphical components in Swing subclass
JComponent
, which is itself a subclass
of the
Container
class in AWT. This basic architectural decision has a number of consequences:
Swing is built on the core classes of AWT, so it inherits the basic AWT model. This means that Swing
applications use the same approach for arranging space (the layout managers, containers, and components) and
handling events. It also means that developers can use similar coding techniques for both Swing and AWT
applications.
Since most Swing components are mostly Java code, there's a lot more flexibility. It's possible to create a much
larger set of graphical components and make them much more customizable since they're basically smart pixels
on-screen.
Swing components are subclassed from Container, so they can all hold other components. This is a big change
from the AWT model, where only a few selected graphical elements were able to hold other items.
Building an entire architecture on another one is not without drawbacks of course. The inheritance hierarchy for
the Swing classes can get fairly complex, and can sometimes make it difficult to see exactly where behavior is
being performed. The
JButton
class is a typical example; its inheritance hierarchy is shown as follows:
Object > Component > Container > JComponent > AbstractButton >
JButton
There are still a few heavyweight classes that remain in Swing. They must be heavyweight in order to interact
with the underlying operating system. The four top-level windowing classes are heavyweights, subclassed from
Table 6-1. AWT and Swing classes
AWT Class
Swing Equivalent
Applet
JApplet
Dialog
JDialog
Frame
JFrame
Window
JWindow
