AWT - Java 1.0 GUI Framework
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 depending 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 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 had to test their applications on each platform—a practice derisively called “write once, debug everywhere.
Swing - New Java GUI Framework Based on AWT
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 functionality required from the underlying windowing system 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.” Swing was available as an extension to Java 1.1 and became a part of the standard library in Java SE 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; besides the Swing components, it also has an accessibility API, a 2D API, and a drag-and-drop API.
Swing is not a complete replacement for the AWT—it is built on top of the AWT architecture. Swing simply gives you more capable user interface components. Whenever you write a Swing program, you use the foundations of the AWT—in particular, event handling. From now on, we say “Swing” when we mean the “painted” user interface classes, and we 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. In our experience, 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 rich and convenient set of user interface elements.
- Swing has few dependencies on the underlying platform; it is therefore less prone to platform-specific bugs.
- Swing gives a consistent user experience across platforms.
Still, the third plus is also a potential drawback: If the user interface elements look the same on all platforms, they look different from the native controls, so 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, Figures 7.1 and 7.2 show the same program running with the Windows and the GTK look-and-feel.
Furthermore, Sun developed a platform-independent look-and-feel that was called “Metal” until the marketing folks renamed it into “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 for being stodgy, and the look was freshened up for the Java SE 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 Java SE 6, Sun improved the support for the native look-and-feel for Windows and GTK. A Swing application will now pick up the color scheme customizations and faithfully render the throbbing buttons and scrollbars that have become fashionable.
Java 7 offers a new look-and-feel, called Nimbus (Figure 7.4), but it is not available by default. Nimbus uses vector drawings, not bitmaps, and is therefore independent of the screen resolution.
Oracle is developing an alternate technology, called JavaFX, that may at some point become a replacement for Swing.
- Core Java,9th Chapter 7 Graphics Programming