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

[ Next Chapter | Previous Section | Chapter Index | Main Index ]