More Abstract Window Toolkit Features

Two weeks ago we talked about event handling in Java's new Abstract Window Toolkit (AWT). This week we're going to discuss some additional new features of the AWT.

Compared to reworking the delivery method for events, the other changes can seem rather mundane. Don't be fooled. This is, as Sun puts it, "undoubtedly one of the most visible and critical pieces of the Java platform," and all of the changes here are important, not only in and of themselves, but also in how they hint at the larger changes to come.

Fortunately, Sun has decided that we shouldn't have to guess forever and actually released a statement about their future plans for AWT development. We're nonplussed. As you'll see from the features we're about to mention, and as you can read in the above-mentioned Web page, there is a continuing attempt to enhance the interface with increasingly complicated features. Some are worthy additions, and some perhaps not.

There are two entirely new widgets: a "Popup" menu and something called a ScrollPlane. The former is designed to facilitate floating menus of the kind popular in recent window systems. (If you're using Windows 95, just right-click anywhere on the exposed desktop to see what  means.) The latter is designed to automate scrollable panels. Where before, panels that wanted to scroll needed to be designed to do so by hand (using the rudimentary scrollbar class), now a single AWT component placed in a scrollplane will be scrollable if it's bigger than the scrollplane itself.

There's now a Data Transfer portion of the API that supports basic clipboard and drag-and-drop activities. In case you've never programmed with these features in the past, let us warn you that it may be a little more complicated than you think. Objects that can be dragged or copied to the clipboard must have implemented an interface that contains the basic requirements for this feature; namely, these objects must be able to negotiate about what formats, or Data Flavors, they can represent themselves in. More on this in the future.

Very sensibly, we think they've finally done the (relatively) simple job of adding some support for "Mouseless Operations" of AWT components. It's now possible to switch from component to component using the Tab key, and there is improved support for the addition of "keyboard shortcuts" to menu items. Equally sensible is the addition of very simple printing support.

Perhaps more intriguing is the addition of support for "lightweight AWT components." We won't go too deeply into this topic yet, but briefly it means that you can now subclass java.awt.Components and java.awt.Containers directly, allowing you to create AWT components that will be almost completely unencumbered by association with native graphical widgets. This allows you to avoid overhead and gain more control over the component's behavior. Sun's demonstration has cute little round buttons that sit transparently on top of the background, where previously ut would have had ugly square borders.

Rounding out the list are some touch-ups to the API's graphics handling routines and a new class called java.awt.SystemColor for providing easy access to your "desktop color scheme" for your applets and applications.

So what's the overall trend? Although it's been called an important feature (and we agree), Sun is moving away from interface components coupled, or peered, with the interface widgets of the native host. It's now an announced intention to provide fully configurable "peerless" (in other words, entirely internal) AWT components as well. This function--to be able to provide an "easily standardizable" interface--as opposed to the old one "blends seamlessly" with the native host environment.

Additionally, there's a rather intriguing system mentioned called "Java 2D;" We get the impression that basic layout and rendering underpinnings of Java are being retooled here. The name also suggests speculation that there may also be a "Java 3D" on someone's drawing board.

Perhaps we're not sensitive enough to the demands of major application developers, but it's our humble opinion that the AWT wish list (and perhaps the wish list for all of Java) should read: 

1. Make it faster
2. Fix the rest of the bugs

Peerless components and fancier layout schemes may be important in the long run, but we can't help being a little worried that JavaSoft may be neglecting serious efficiency and reliability concerns in the throes of the feature craziness that so many developers suffer from.

At any rate, we're happy to take the good with the slightly forboding: On the balance, we're quite pleased with the current round of changes to the AWT. Check out the AWT enhancements page for details, and come back and visit next week.

Past installments of Java Jolt