Section 7.8
Looking Forward: Swing and Java 2
JAVA PLATFORM 2.0 HAS BEEN OUT for over a year.
Java Platform 2.0 is the name that Sun Microsystems uses, somewhat confusingly,
for version 1.2 of the Java language plus some optional features that make it suitable
for large-scale business applications. In the transition from Java 1.0 to Java 1.1,
many features were "deprecated," meaning that it is no longer advisable
to use them. The same was not true in the transition from Java 1.1 to 1.2.
With only a very few minor exceptions, everything in Java 1.1 carries over
unchanged to Java 1.2. This textbook covers Java 1.1, but everything in
it is valid for Java 1.2 and Java Platform 2.
Even in Java 1.1, there are many features that I will not cover.
These features take the form of standard classes that provide various
capabilities. For example, Java 1.1 includes a set of classes that are
used for RMI (Remote Method Invocation).
RMI allows a program running on one computer on a network to use objects that
exist on other computers on the network. The methods of that
object are "invoked", that is called, remotely.
One especially important advanced feature of Java 1.1 is the
Java Bean technology. A Java Bean is simply
an object that follows certain programming guidelines. All the GUI
components in java.awt are Beans, for example. An object
that follows the guidelines can be used in a Bean Builder application,
which is a visual development tool that lets application developers
assemble programs from pre-existing parts. The parts are Java Beans.
Java Beans have properties. A property
is just a value associated with the bean. A property has a name.
If PropName is a property, then the bean contains one
or both of the methods getPropName() and setPropName()
for reading and changing the value of the property. To
define a property named PropName, the bean doesn't have to
do anything more than define these methods. This is one of the
programming guidelines for beans. A Bean Builder application can
recognize a property by looking for these methods, and it will make
it possible for an application developer to manipulate these
properties.
To make it easier to work with properties, Java 1.1 defines a
PropertyChangeEvent class and an associated PropertyChangeListener.
A bean can generate a PropertyChangeEvent when one of its properties changes.
It can define an addPropertyChangeListener() method so that
other objects can be registered to receive notification when the value of
a property changes. A Bean Builder can check for this method to determine
whether a bean supports property change events.
Perhaps the most visible change from Java 1.1 to Java 1.2 is
the introduction of a new set of GUI components called "Swing."
Swing components can be used as an alternative to the components
defined in the AWT. Swing uses the idea of properties and
PropertyChangeEvents extensively. It also adds a similar
event type, ChangeEvent, which carries less information
than a PropertyChangeEvent and can therefore be handled more
efficiently.
In addition to Swing, Java 1.2 introduces a few other new
features. For example, it includes classes to support Drag
and Drop (the ability to drag information from one component and
drop it on another, even between Java and non-Java programs) and
Accessibility (classes that support access to Java programs, including
Swing components, by tools that such as audible text readers, which
can help to make a program accessible to the blind).
Java 1.2 also includes a greatly enhanced two-dimensional
graphics capability. (A three-dimensional graphics package is
available as an optional add-on.) This takes the form of
a new class, Graphics2D, which is a subclass of the
Graphics class that is used in the AWT. In addition to
the graphics routines from the Graphics class, a Graphics2D
object includes support for additional shapes, curves, lines that are more
than one pixel thick, and dotted and dashed lines. In addition, it
has support for geometric transformations, which means that it is possible
to apply rotation, scaling, and translation operations to whatever is
drawn in the graphics context.
Swing
Swing consists of a collection of classes defined in the
package javax.swing. Swing builds on the
basic functionality of the AWT, including the Component
and Container classes and all the layout manager, event, and listener classes,
but it replaces the actual GUI components from the AWT with a new
set of GUI components. For each type of GUI component in the AWT,
there is a corresponding class in Swing. The java.awt.Button class
is replaced by javax.swing.JButton. The java.awt.Frame
class is replaced by javax.swing.JFrame. The
java.applet.Applet class is replaced by javax.swing.JApplet.
And so on. There are a few differences between the AWT components and
the corresponding Swing components, so it is not quite possible to
take an existing AWT program and convert it into a Swing program
by adding a "J" to all the class names. But the other changes that
are needed are minor. One significant change is that it is
not possible to add components directly to a JApplet
or JFrame. The components have to be added to something
called the "content pane" with a command such as
"getContentPane().add(comp);". Another difference is that
there is no JCanvas class. A Swing program would most likely use
a JPanel as a replacement for an AWT canvas.
However, Swing extends these AWT-like components with a large number
of new component classes. For example, there is a JTable class
for making two-dimensional tables like those used in a spreadsheet.
There is a JTabbedPane that is something like a CardLayout
except that there are "tabs" on the tops of the cards that the user can
click to move from one card to another. A JToolBar consists of
a row or column of icons that the user can click to perform various commands.
A JSplitPane is divided into two sections, with a divider between
them. The user can move the divider to change the sizes of the two sections.
There is a text editor pane -- something like a TextArea --
that supports a mixture of different sizes and styles of text.
You've probably seen all these things in modern GUI programs, but they
are not available in the AWT.
Furthermore, the components in Swing have more capabilities individually
than those in the AWT. For example, the JPanel class can support
double buffering automatically. Buttons and labels can display images
instead of or in addition to text. A component can have an associated
"tool tip" that pops up in a little window when the user points the
mouse at the component.
So, you might be asking, why not just use Swing instead of the AWT
exclusively? It might be that in the future, everyone will do so.
However, there are still some reasons to use the AWT. For one thing,
the enhanced capabilities of Swing come at a cost of increased
complexity. Programming for any GUI is hard. Programming for a
modern, full-featured GUI like that implemented by Swing is proportionately
harder. Furthermore, Java 1.2 is still not as widely available in
Web browsers as Java 1.1, and it is such a large system that it is not
clear how quickly it will be deployed. Java 1.1 seems to me to be
quite suitable for the kind of small application that is likely to
appear on a Web page. It is also my guess that it will take some time
for a system as large and complex as Swing to become completely stable.
Another question that arises is, why was Swing implemented as
a separate package? Why not just add more components to the AWT?
The reason here is that there are a lot of architectural (under-the-hood)
innovations in Swing. A Swing component is really a different sort of
thing from an AWT component, even though they have similar looks and
behaviors. It is not possible to mix Swing and AWT components in
the same program (unless you really, really know why you are doing).
Every AWT component has a so-called "native peer", which is the
GUI component that you actually see on the screen. This peer
is created and controlled by the native operating system (Windows,
Mac OS, Unix). In an AWT program, there are many such native components.
In a Swing, there is only one, corresponding to the entire
window or applet. The other Swing components are written entirely in
Java. They are drawn using Java graphics. Their events are processed
entirely by methods written in Java. This means that Swing components
should work more consistently on different platforms.
Furthermore, a Swing component has a double structure. It consists
of a model and a user
interface delegate, or UI delegate.
The model is an object that holds
the component's data, such as the text in a JTextArea or
the numbers in a JTable. The UI delegate
is an object that is in charge of drawing the component and handling
events associated with that component. It is possible to provide
different views of the same data by using the same model for several
components. The model can communicate with a UI delegate
with ChangeEvents. When the data in the model changes, a
ChangeEvent informs the UI delegate, and it redraws the
component to reflect the change. This structure makes it possible
for Swing to implement "pluggable look-and-feel". It's possible
to change the whole visual style of a program by installing a new
set of UI delegates, without changing the underlying data in the models.
This makes it possible for a program to look and feel like a Windows
program on a Windows computer, while the same program looks and feels
like a Macintosh program on a Mac. It is even possible to change
the look-and-feel of a program while it is running.
Obviously, this has been only the briefest of introductions to
Swing. Actually using it requires ascending a steep learning curve.
However, I think you'd find that what you've learned about the AWT is
a good foundation for learning about Swing.
End of Chapter 7
