Java Reference
In-Depth Information
AWT and Swing - The Graphical User Interface APIs
Packages
Primary AWT packages are
java.awt
and
java.awt.event
Other packages include
java.awt.color,
java.awt.datatransfer, java.awt.dnd, java.awt.font, java.awt.geom, java.awt.im,
java.awt.im.spi, java.awt.image, java.awt.image.renderable, java.awt.print
Use:
J2SE (JDK1.0, greatly expanded in JDK1.2 and 1.3)
Primary Swing package is
javax.swing
Other packages include
javax.swing.border, javax.swing.colorchooser, javax.swing.event,
javax.swing.filechooser, javax.swing.plaf, javax.swing.plaf.basic, javax.swing.plaf.metal,
javax.swing.plaf.multi, javax.swing.table, javax.swing.text, javax.swing.text.html,
javax.swing.text.html.parser, javax.swing.text.rtf, javax.swing.tree, javax.swing.undo
.
Use:
J2SE (since JDK1.2, expanded for JDK1.3)
Common Features
Central to both AWT and Swing are the concepts of the
component, container,
and
layout manager.
A component
is a graphical element of some kind like a button, label or text box. A container is also a kind of graphical element,
but is distinguished by its ability to hold other elements. Containers are the organizers of the Java graphics APIs,
enabling developers to group graphical elements within the GUI space. Windows are containers, holding
components such as buttons and checkboxes inside themselves.
Layout managers are not graphical. They're worker objects, specialists that can determine size and position for
components inside a container. A container delegates the task of managing its space to its associated layout
manager, relying on it for advice about how and where it should place elements.
Another important feature of AWT and Swing is the event-handling model. In Java graphical applications, user
interaction is represented by event objects that are produced by components. For example, if a user were to click
on a big red button in a Java GUI labeled “History Eraser”, that button would produce an
ActionEvent
.
So would this act irrevocably erase our existence? Luckily, not in this universe. Unless there is an associated event handler, the event
produced will not trigger any program response. In this example, there has to be a class implementing the
ActionListener
interface which has been registered with the button through a call to
addActionListener
. In that case, the
ActionEvent
is passed to the associated
ActionListener
through a call to its
actionPerformed
method. To
date, no one has written an event handler for the History Eraser button, so we're all still safe.
The AWT Architectural Model
The Abstract Window Toolkit (AWT) has been around as long as the language itself. It is built around a simple
set of components that allow you to create basic GUIs. When you create an AWT application, its components are
guaranteed to have the same look and feel as the platform where JVM runs. In other words, the same code
produces a Solaris GUI when run on Solaris, a Macintosh GUI on MacOS and a Windows GUI on a Wintel
platform.
There's a very straightforward explanation for this—an AWT application looks like its elements are native to a
platform because they really are. AWT bases its functionality on the concept of the
peer.
Every AWT component
has a peer class associated with the operating system, which does most of the real work. The classes that
developers use to create graphical components in AWT provide a programming wrapper around the peers. For
instance, in AWT a programmer uses the
java.awt.Button
class to create a button. Associated with that button
is an implementor of the
java.awt.peer.ButtonPeer
interface, which performs most of the real tasks associated
with painting the component on-screen.
It follows that there must be some way to keep track of the platform-specific peers within AWT. The
Toolkit
class provides that capability. Inside
Toolkit
is the code used to link to the underlying operating system.
Developers rarely use this class directly, but it is important to AWT, since it ultimately loads graphical libraries,
creates peer objects, and manages other platform-dependent resources such as cursors.
Because the basic AWT components are directly linked to the underlying operating system through their peers,
they are also referred to as
heavyweight components
since they rely directly on the operating system to do things
