| When Java 1.0 was introduced, it contained a class library, which Sun called the Abstract Window Toolkit (AWT), for basic GUI programming. The way the basic AWT library deals with user interface elements is to delegate their creation and behavior to the native GUI toolkit on each target platform (Windows, Solaris, Macintosh, and so on). For example, if you used the original AWT to put a text box on a Java window, an underlying "peer" text box actually handled the text input. When writing these kinds of AWT programs, the idea was that you simply specify the location and behavior of your user interface elements, and Java would create the peers. The resulting program could then, in theory, run on any of these platforms, with the "look and feel" of the target platform hence Sun's trademarked slogan "Write Once, Run Anywhere." The peer-based approach worked well for simple applications, but it soon became apparent that it was fiendishly difficult to write a high-quality portable graphics library that depended on native user interface elements. User interface elements such as menus, scrollbars, and text fields can have subtle differences in behavior on different platforms. It was hard, therefore, to give users a consistent and predictable experience with this approach. Moreover, some graphical environments (such as X11/Motif) do not have as rich a collection of user interface components as does Windows or the Macintosh. This in turn further limits a portable library based on peers to a "lowest common denominator" approach. As a result, GUI applications built with the AWT simply did not look as nice as native Windows or Macintosh applications, nor did they have the kind of functionality that users of those platforms had come to expect. More depressingly, there were different bugs in the AWT user interface library on the different platforms. Developers complained that they needed to test their applications on each platform, a practice derisively called "write once, debug everywhere." In 1996, Netscape created a GUI library they called the IFC (Internet Foundation Classes) that used an entirely different approach. User interface elements, such as buttons, menus, and so on, were painted onto blank windows. The only peer functionality needed was a way to put up windows and to paint on the window. Thus, Netscape's IFC widgets looked and behaved the same no matter which platform the program ran on. Sun worked with Netscape to perfect this approach, creating a user interface library with the code name "Swing" (sometimes called the "Swing set"). Since, as Duke Ellington said, "It Don't Mean a Thing If It Ain't Got That Swing," Swing is now the official name for the non-peer-based GUI toolkit that is part of the Java Foundation Classes (JFC). The full JFC is vast and contains far more than the Swing GUI toolkit. JFC features not only include the Swing components but also an accessibility API, a 2D API, and a drag-and-drop API.  Swing is not a complete replacement for the AWT. Swing simply gives you more capable user interface components. The basic architecture of the AWT, in particular, event handling, remains the same as it was in Java 1.1. (AWT event handling underwent a significant change between Java 1.0 and Java 1.1.) Swing uses the 1.1 event handling model, and a version of Swing can even be downloaded from Sun's web site for use in Java 1.1 programs. And, although the AWT peer-based user interface components are still available, you will rarely, if ever, want to use them. From now on, we'll say "Swing" when we mean the "painted" non-peer user interface classes, and we'll say "AWT" when we mean the underlying mechanisms of the windowing toolkit, such as event handling. |
Of course, Swing-based user interface elements will be somewhat slower to appear on the user's screen than the peer-based components used by the AWT. Our experience is that on any reasonably modern machine, the speed difference shouldn't be a problem. On the other hand, the reasons to choose Swing are overwhelming: Swing has a much richer and more convenient set of user interface elements. Swing depends far less on the underlying platform; it is therefore less prone to platform-specific bugs. Swing will give a consistent user experience across platforms.
All this means Swing has the potential of finally fulfilling the promise of Sun's "Write Once, Run Anywhere" slogan. Still, the third plus is also a potential drawback: if the user interface elements look the same on all platforms, then they will look different from the native controls on at least some platforms, and thus users will be less familiar with them. Swing solves this problem in a very elegant way. Programmers writing Swing programs can give the program a specific "look and feel." For example, Figure 7-1 and 7-2 show the same program running with the Windows[1] and the Motif look and feel. [1] For what are apparently copyright reasons, the Windows and Macintosh look and feel are available only with the Java runtime environments for those platforms.
Figure 7-1. The Windows look and feel of Swing 
Figure 7-2. The Motif look and feel of Swing 
| While we won't have space in this book to tell you how to do it, it is possible for Java programmers to extend an existing look and feel or even design a totally new look and feel. This is a tedious process that involves specifying how various Swing components need to be painted, but some developers have done just that, especially when porting Java to nontraditional platforms such as kiosk terminals or handheld devices. See the "Swing Connection" at http://java.sun.com/products/jfc/tsc/ for more on this process. |
Furthermore, Sun developed a platform-independent look and feel that they call "Metal," which we think looks very nice (see Figure 7-3). In this book, we will use Swing, with the Metal look and feel, for all our graphical programs. Figure 7-3. The Metal look and feel of Swing 
In sum, Swing is more robust, has more features, is more portable, and is easier to use than the peer-based AWT user interface components. We feel strongly that Swing is the future of user interface programming in Java, and we think that you will want to use it for all your new Java programming projects. Finally, we do have to warn you that if you have programmed Microsoft Windows applications using VB, Delphi, or Visual C++, you know about the ease of use that comes with the graphical layout tools and resource editors these products provide. These tools let you design the visual appearance of your application, and then they generate much (often all) of the GUI code for you. Although some GUI builders are now available for Java programming, these products are not as mature as the corresponding tools for Windows. In any case, to fully understand graphical user interface programming (or even, we feel, to use these tools effectively), you need to know how to build a user interface manually. Naturally, this often requires writing a lot of code. |
