The Mathematics of GUIs

AWT and Swing

In 1996, when Java was first becoming popular, GUI components were part of the “abstract window toolkit” or AWT package. By design, AWT components were dependent on host platform resources for their appearance and behavior. This meant that a Java button on a Macintosh, for instance, would look and behave like a native Macintosh button, but when running on a Microsoft Windows platform, for instance, would look and behave like a native Microsoft Windows button. The API for the Java components was consistent from platform to platform but each component deferred to a platform-specific component “peer” that was responsible for its actual appearance and behavior. So, java.awt.Button deferred to java.awt.peer.ButtonPeer, java.awt.List deferred to java.awt.peer.ListPeer and java.awt.MenuBar deferred to java.awt.peer.MenuBarPeer ( to name just a few ). At first, this was deemed to be a strength of the AWT design. For Java applications to have conquered multiple platforms — even to the point of looking as though they were native to each platform — seemed like the quintessential achievement of the “write once, run anywhere” dream.

Unfortunately, this approach proved to be limiting. “write once, run anywhere” could keep its promise only by supporting just those features that all platforms had in common. If, for example, Macintosh had a great GUI feature that Microsoft Windows didn’t, the AWT couldn’t provide a platform independent API that included that feature because it would break on Microsoft Windows platforms. Consequently, the feature wouldn’t be offered at all. Being constrained to the intersection of platform features virtually guaranteed that Java GUIs would have fewer capabilities than their non-Java counterparts. Furthermore, the supposed strength of being native proved to be a nuisance due to the unavoidable inconsistencies between platforms.

It was inevitable that solutions to this problem would be invented and, in 1997, a project at Sun Microsystems with code name “Swing” was responsible for creating a package of pure Java GUI components that was not dependent on native resources. These classes were known as the JFC or “Java Foundation Classes” and were initially offered as a pure Java extension to the JDK. They became a standard part of the Java 2 Platform with version 1.2. Because they are not dependent on native resources, Swing components are known as “lightweight” components to distinguish them from “heavyweight” AWT components. Being pure Java, they can offer a virtually unlimited number of features — anything that can be expressed in Java. Consequently, the Swing package has grown to be immense and very powerful, overshadowing the AWT in many respects. There are still occasions when the AWT is the best choice ( e.g. when using the Java3D extension package which is designed to take advantage of graphics hardware that can only draw on native resources ), but these are the exceptions. Whenever possible, it is advisable to choose Swing over AWT.

Naming Conventions

AWT components are located in the java.awt package while Swing components are located in the javax.swing package. In general, if a Swing component has an AWT counterpart, its name is the same as its AWT counterpart’s name except that it is preceded by the letter “J”. In this chapter, when clarity requires, a component will be referred to by its fully qualified name as in “java.awt.Component” (for an AWT component) or “javax.swing.JComponent” (for a Swing component). In other cases it will be referred to by its short name as in “Component” or “JComponent”. If a component archetype is being discussed and it doesn’t matter whether it’s AWT or Swing, then it will be referred to by its AWT name without capitalization as in “component” or “button”. Hopefully this will be clear in context. This chapter concentrates on Swing GUI programming and talks about the AWT only where it has relevance due to inheritance or because there was never a need to supplant it.