TheAbstract Window Toolkit (AWT) isJava's original platform-dependentwindowing,graphics, anduser-interfacewidget toolkit, precedingSwing. The AWT is part of theJava Foundation Classes (JFC) — the standardAPI for providing agraphical user interface (GUI) for a Java program. AWT is also the GUI toolkit for a number ofJava ME profiles. For example,Connected Device Configuration profiles require Javaruntimes onmobile telephones to support the Abstract Window Toolkit.
WhenSun Microsystems first released Java in 1995, AWT widgets provided a thin level of abstraction over the underlying native user-interface. For example, creating an AWTcheck box would cause AWT directly to call the underlying native subroutine that created a check box. However, the check box onWindows is not the same as the check box onmacOS or on the various types ofUnix. Some application developers prefer this model because it provides a high degree of fidelity to the underlying native windowing toolkit and seamless integration with native applications. In other words, a GUI program written using AWT looks like a native Microsoft Windows application when run on Windows, but the same program looks like a nativeApple Macintosh application when run on a Mac, etc. However, some application developers dislike this model because they prefer their applications to look exactly the same on every platform.
InJ2SE 1.2, theSwing toolkit largely superseded the AWT's widgets. In addition to providing a richer set of UI widgets, Swing draws its own widgets (by usingJava 2D to call into low-level subroutines in the local graphics subsystem) instead of relying on the operating system's high-level user interface module. Swing provides the option of using either the native platform's"look and feel" or a cross-platform look and feel (the "Java Look and Feel") that looks the same on all windowing systems.
The AWT provides two levels ofAPIs:
java.awt.datatransferpackage for use with theClipboard andDrag and Drop.Canvasobject drawing surface.AWT also makes some higher level functionality available to applications, such as:
Neither AWT nor Swing is inherentlythread safe. Therefore, code that updates the GUI or processes events should execute on theEvent dispatching thread. Failure to do so may result in adeadlock or race condition. To address this problem, a utility class calledSwingWorker allows applications to perform time-consuming tasks following user-interaction events in the event dispatching thread.
Where there is a Swing version of an AWT component it will begin with J- and should be used exclusively, replacing the AWT version. For example, in Swing, only use JButton, never Button class. As mentioned above, the AWT core classes, such as Color and Font, are still used as-is in Swing.
When drawing in Swing, use JPanel and override paintComponent(Graphics g) instead of using the AWT paint() methods.
BeforeJava 6 Update 12, mixingSwing components and basic AWT widgets often resulted in undesired side effects, with AWT widgets appearing on top of the Swing widgets regardless of their definedz-order. This problem was because the rendering architecture of the two widget toolkits was very different, despite Swing borrowing heavyweight topcontainers from AWT.[1]
Starting inJava 6 Update 12, it is possible to mix Swing and AWT widgets without having z-order problems.[2]
importjava.awt.*;importjava.awt.event.WindowAdapter;importjava.awt.event.WindowEvent;publicclassMyApp{publicstaticvoidmain(String[]args){Frameframe=newFrame("Application");frame.add(newLabel("Hello!"));frame.setSize(500,500);frame.setLocationRelativeTo(null);// Centers the windowframe.addWindowListener(newWindowAdapter(){@OverridepublicvoidwindowClosing(WindowEvente){frame.dispose();// Releases native screen resources}});frame.setVisible(true);}}
As the AWT is a bridge to the underlying native user-interface, its implementation on a newoperating system may involve a lot of work, especially if it involves any of the AWT GUI widgets, because each of them requires that its native peers be developed from scratch.
A new project,Caciocavallo, has been created, that provides anOpenJDK-based Java API to ease AWT implementation on new systems.[3][4] The project has successfully implemented AWT widgets usingJava2D.[5] All the necessary core-JDK modifications have since been pushed toOpenJDK 7,[6] which means that Java can now be used on a graphics stack other than one of those provided by the official JDK (X Window System,OpenGL orDirectX), by including an external library and setting some system properties. ADirectFB backend for Caciocavallo[7] is under development, as is anHTML5 backend; the aim is to deploy existing Swing applications—without Java support—as ordinary web applications running on a web server.[7][8]
You don't need anymore of those patches, with the latest FontManager push, everything is upstream now, so just use the Cacio repo, it's completely self contained.
java.awt (AWTJavadoc API documentation)