AWT: The Next Generation
The Abstract Window Toolkit (AWT)
is the API responsible for building the graphical user interface (GUI)
for Java programs.
The AWT is undoubtedly one of the most visible and critical
pieces of the Java platform. JavaSoft's goal is to ensure that the AWT
meets the increasing demands of developers who are building innovative and
competitive products for the Java platform.
The AWT in 1.0 was designed for building GUIs for
fairly simple Java applets. It is clear that the AWT must migrate towards
providing a framework for more powerful and complex GUI development.
Since this migration is a large effort, we are working on it in phases.
The AWT in JDK 1.1 is the first phase of this development.
We are currently working on the second phase, which is not yet part of an
announced JavaSoft product, but which we anticipate will be released
(possibly in stages) in the 1997 calendar year. This next phase includes many
exciting changes to the AWT, including some fairly major architectural
enhancements. We know the development community is quickly pushing the
envelope of the current 1.0 platform and is anxious to understand our future
direction.
Therefore, this document provides some high-level information
about our direction.
Note:
We reserve the right to change our plans.
A glimpse at highlights of the next phase...
One of the problems with the 1.0 AWT is that creating new components requires
creating subclasses of Canvas or Panel.
The side effect is that each new
component owns its own opaque native window.
This one-to-one mapping between components and native windows
results in three big problems:
- Windows can be heavyweight,
so it's bad to have too many of them.
- Windows are opaque,
so they can't be used to implement transparent regions.
- Windows are handled differently across platforms,
so the AWT has to struggle
to maintain a consistent view across these varied platforms.
We are developing a lightweight component framework that makes it possible to
have components that do not require their own native windows.
Instead, a lightweight component uses a native window provided
by one of its containing ancestors.
Lightweight components fit
into the existing AWT models (rendering, layout, and so on),
allowing lightweight components to be
combined with existing AWT components to create lighter-weight interfaces.
A major benefit of this framework is that
it will be completely implemented in common Java code,
so that the behavior is guaranteed to work consistently across
platforms.
The peer model in the AWT was designed
for the sole purpose of being able to provide
a truly native look-and-feel
by delegating the look-and-feel of the components
to a set of underlying "peer" classes.
Each platform has a different set of peer classes
to wrap the native system's widgets.
While this design works well for its intended goal,
it suffers from a number of deficiencies:
- Changing the look of components is difficult.
- Native widgets behave slightly differently on different platforms.
This causes inconsistencies
that the AWT must try to alleviate with complex logic.
- The peer model provides no option of a common look & feel.
We are exploring providing "peerless" versions of the components,
such that they are 100% implemented in common Java code.
We would continue to provide
the peer option for those who require (or desire) the truly
native look-and-feel. However, the peerless option would exist for those who
prefer a common look-and-feel across platforms and wish to easily change
the components' appearance.
By default, the 1.0 AWT provides a native look-and-feel,
determined at runtime,
that matches the particular platform it is running on.
Because the look-and-feel is truly native,
it varies from platform to platform.
We've discovered that a large community would like the option of selecting a
common look-and-feel across the platforms. We believe the right
way to do this is to make this look-and-feel "pluggable", which means that the
default look-and-feel of components is delegated to a separate set of
look-and-feel objects and rendering functions.
The basis of this architecture will
allow look-and-feel customization at three levels:
- Completely replace the whole look-and-feel by providing a separate
look-and-feel implementation.
- Customize parts of the the default look-and-feel implementation to provide
consistent modifications across components (for example, change the depth
of a border's shadow).
- Customize the look-and-feel of just an individual component subclass.
Note that this differs from today's peer model in that it is all implemented
in Java and all the necessary hooks will be provided to allow easy extending
of components.
Drag-and-Drop has become an expected feature of most modern interfaces today.
We have been working on a general data transfer architecture,
on top of which the API for Clipboard and Drag-and-Drop will be built.
We have introduced this data transfer mechanism in JDK 1.1,
along with the Clipboard API,
and will provide the Drag-and-Drop API in the following release.
You can read the
Data Transfer design document for more details.
The graphics model in the 1.0 JDK provided only basic rendering capabilities.
We realize the need to provide
more graphically rich rendering and visual effects.
We have been working jointly with major partners on a new Java 2D
API that layers into the AWT and dramatically extends its capabilities.
This API provides complex rendering that supports
arbitrary transformations (rotation, scaling, and so on),
image compositing,
sophisticated text handling,
and more.
- Copyright © 1996, Sun Microsystems, Inc.
- Last updated December 6, 1996
- Send feedback to:
java-awt@java.sun.com