When Java 1.0 was introduced, it contained a class library, which Sun called the Abstract Window Toolkit (AWT), for basic GUI programming. The basic AWT library deals with user interface elements by delegating 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. 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"). Swing was available as an extension to Java 1.1 and became a part of the standard library in JDK 1.2. 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. Swing 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. NOTE
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:
All this means Swing has the potential of 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 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.
Figure 7-1. The Windows look and feel of SwingFigure 7-2. The Motif look and feel of SwingNOTE
Furthermore, Sun developed a platform-independent look and feel that was called "Metal" until the marketing folks renamed it as the "Java look and feel." However, most programmers continue to use the term "Metal," and we will do the same in this book. Some people criticized Metal as being stodgy, and the look was freshened up for the 5.0 release (see Figure 7-3). Now the Metal look supports multiple themes minor variations in colors and fonts. The default theme is called "Ocean." In this book, we use Swing, with the Metal look and feel and the Ocean theme, for all our graphical programs. Figure 7-3. The Ocean theme of the Metal look and feelNOTE
Finally, we do have to warn you that if you have programmed Microsoft Windows applications with Visual Basic or 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 GUI builders are 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. |