AWT

The primary GUI toolkit for the Java framework. The idea is very simple and smart, on the whole -- the JVM will, instead of supplying it's own GUI controls, simply transalate object references into the host system's own widgets. Meaning that if my AWT based Java App says 'put a button here', the JVM doesn't use it's own button, but instead asks the OS to draw what it uses as a button here. This system allows for very compact and fast(er) code, but also suffers because not all controls are implimented with the same properties across all platforms, etc. Contrast this with Swing/JFC.

AWT, the Abstract Window Toolkit, was introduced with version 1.0 of Java. It provides a class library for basic GUI development - event handling, user interface elements, and so on.

Sun's goals for AWT were that it be fast, lightweight, and support the "Write Once, Run Anywhere^TM" Java slogan. In order to achieve this for the user interface elements (text boxes, buttons, menu items, and so on), AWT delegates the creation and behaviour of these elements to the underlying OS and its native GUI toolkit. Thus, using AWT, a button created on Windows looks and acts like a Windows button - similarly for Mac, Solaris, and so on. The user of a program developed with AWT has a "native platform" look and feel as a result. As well, use of the native widgets means the performance is as fast as possible.

This approach sounds reasonable, and works well for simple applets and applications, but is fraught with problems for commercial software development. First of all, some of the underlying platforms, such as X/Motif on Solaris, have very rudimentary GUI primitives.This significantly limits the functionality that AWT can provide. AWT has to be portable, so the functionality AWT can support is limited to this lowest common denominator. Programs created with AWT have the feel of their native platforms, but lack the rich functionality that users of those platforms expect.

Second, the fact that the UI elements are created by the underlying OS toolkit means that the behaviour and presentation of these elements can be inconsistent between platforms. Developers get not only the look and feel of the native OS, but all of the quirks and bugs as well. This results in the need to perform a full interface QA cycle on each platform your software is intended to support - derisively called "Write Once, Debug Everywhere" by Java developers.

These problems led to the development of JFC/Swing, a new class library that implements user interface elements directly in Java. Swing provides a rich set of UI elements, and where bugs exist, at least they are the same bugs on all platforms. "Swing" is in the core library set of Java 2, and a Swing JAR is available for use in Java 1.1 applications (but not applets, as most browsers support Java 1.1.5, which is too primitive).

The arrival of Swing means that AWT is no longer used for user interface elements in Java client porgramming. However, AWT is far from dead - the AWT event handling model, in particular, is still the basis for Java GUI development. Swing has merely supplanted the UI widgets of AWT, not the entire class library.