Sun gives Java's abstract windowing toolkit a brighter future
When it comes to the future of the Java GUI, Sun has some exciting plans. Last week’s JavaOne conference was the forum for demos of what’s in store for the next generation of the Abstract Windowing Toolkit (AWT). And although the new technologies build on some of the tools of the current AWT, in many ways these technologies supplant the existing component set with more flexible, more portable replacements.
The AWT is composed of a set of basic components — such as buttons, labels, and scrolled lists — and containers, which group components (and possibly other containers) together according to a given layout policy. The current AWT components all require associated “peer” classes, which are built using native code, to implement the user interface. This design makes it possible to take advantage of the platform-specific characteristics of these basic GUI components. In addition, native peer classes often are faster for compute-intensive tasks, such as text manipulation and scrolling. This feature was especially helpful back in the days before just-in-time (JIT) compilers.
This original AWT design, however, has a number of flaws. Existing components are difficult to extend because much of the processing (event handling and painting) is done at the “peer” level. Often, this processing cannot be intercepted or overridden. Java applications that attempt to do even moderately complex things with the GUI often show bad side effects when those Java apps run under a different operating system.
The new AWT will build on the Lightweight User Interface Framework that was introduced as part of the Java Development Kit (JDK) 1.1, released in February. This framework allows the development of AWT containers and components that don’t require native “peer” classes. These containers and components are therefore “100% Pure Java” and, as such, should be platform independent.
This new design actually gives the component designer much more control over such things as:
Z-ordering — the order in which components are drawn to the screen, and how mouse events are intercepted
Component shapes — non-rectangular shapes will be possible
- Transparency — drawing some components with transparent backgrounds, and allowing the background of their container to show through
The Lightweight User Interface Framework, as delivered in JDK 1.1, does not actually include any of these components yet. But the building blocks are there to support future components, and you can use them to design your own lightweight components. These building blocks are actually just new versions of the original Component and Container classes. These new versions do not require a peer object, and if one is not provided, they will manage the paint requests and event distribution.
Lightweight user interfaces are nothing new. In fact, JavaSoft has been under a lot of pressure to come up with an alternative to its original strategy. In lieu of a near-term solution, several companies, developed very similar frameworks on top of the 1.0.2 AWT. (See the Resources section for information on some of these frameworks.) Without these interim frameworks, developers do not have the tools to build reliable, robust, multiplatform Java programs. Fortunately, for now, these third-party tools do exist. But for those projects that can wait, JavaSoft will soon deliver (probably by year’s end) a version of the JDK with lightweight component replacements for all current AWT components.
JavaSoft’s new AWT warrants serious consideration for two reasons: It will support some planned Java features, and it will be the basis for other Java technologies. JavaSoft has organized a small group of developers — the “Swing Team” — to develop these new components. One focus of the Swing Team’s efforts will be on designing in a powerful feature called “pluggable” look and feel, which allows a separation of the GUI style from the function of the AWT components.
JavaSoft has developed software representation of the three major Java platforms (Macintosh, Windows, and Unix’s Motif) already, giving its new AWT components the ability to look and work like Macintosh, Windows, or Motif components. In fact, all these GUI configurations are available on any platform, and the GUI style can even be changed on the fly. For example, you can run one of these Java programs on a Motif platform and give it a Windows or Macintosh look and feel.
The pluggable look and feel has other possibilities, as well. JavaSoft did not simply add a bunch of hard-coded tests to its component software to check for Macintosh, Windows, or Motif and do something different. Instead, it defined what it calls “User Interface (UI) factories,” which hold the data and algorithms that represent a given UI style. One or more UI factories can be applied to a single component, to a type of component (for example, all radio buttons), or to an entire application. And Java programmers can define their own custom styles.
JavaSoft has more in mind here than just letting developers or users personalize their applications (although that is certainly a feature). The UI factory can be used to define a corporate look and feel for companies that want their applications to conform to a certain standard style. UI factories could even be used to define a look and feel specifically for disabled persons. This application, JavaSoft claims, may even go as far as redefining the input and output devices associated with a user interface, to control Braille or audio feedback, or voice recognition input.
These lightweight and pluggable technologies will become part of a newly announced user interface framework called the Java Foundation Classes (JFC). JFC will include all the basic AWT components (like buttons, checkboxes, lists, and text fields), some new simple components (like icons, tooltips, sliders, gauges, and spin boxes), plus a number of very useful higher-level components, now found standard on the Windows and Macintosh platforms. These higher-level components include tree views (often used for hierarchical displays like directory structures and files), table and list views, tabbed folders, pane splitters, toolbars, color and font choosers, and rich-text editors. JFC is being jointly developed by Sun, Netscape, and IBM, and will leverage some of the GUI technology developed for Netscape’s Internet Foundation Classes (IFC).
Other related user-interface enhancements soon to come include drag-and-drop and the use of the new Java 2D API. Drag-and-drop will take advantage of the same framework now available in JDK 1.1 for clipboard data transfer. Although drag-and-drop functionality was planned for 1.1, it didn’t make the deadline. JavaSoft claims to be giving this feature the highest priority, and is also planning to include the ability to drag objects between Java applications and native applications.
The Java 2D API, developed cooperatively by JavaSoft and Adobe, is one of the most extensive 2D graphics APIs ever published in a public library. It adds features like anti-aliased text and graphics, generic and resolution-independent definition of complex objects through Bezier paths, transformations, more color, fonts, transparency options, and more. All these features will be merged with the new AWT in the can’t-be-soon-enough future. The Swing Team may use the new Java 2D features to create things such as true non-rectangular components, more font choices, and slanted, skewed, rotated, or otherwise-transformed GUI objects and applications.
JavaSoft is planning an early release of the new lightweight AWT, separate from an official JDK release, in May. Public feedback is encouraged (send email to java-awt@java.sun.com). Drag-and-drop, custom cursors, and some other features will be incorporated in the next major JDK release (JDK 1.2), but some of the other new AWT features may not be part of the standard JDK distribution until some release beyond 1.2 (still to be announced).
For user interface designers and programmers developing full-scale Java applications, these technologies will solve most, if not all, of the problems that plague the current AWT architecture. The demonstrations shown at JavaOne reveal a toolset nearing maturity. If the new AWT is released soon, it should do a lot to head off the adoption of other third-party tools, which might otherwise cause applications to diverge from one another in terms of look and feel. Only time will tell, but I am encouraged.
