Abstract Window Toolkit: Difference between revisions

Revision as of 02:33, 13 November 2022

Revision as of 14:23, 1 June 2023

Line 3:

[[File:Easy Java AWT example.jpg|thumb|250px|Windows form with some AWT examples]]

The '''Abstract Window Toolkit''' ('''AWT''') is [[Java (programming language)|Java]]'s original platform-dependent [[Windowing system|windowing]], [[graphic]]s, and [[user-interface]] [[widget toolkit]], preceding [[Swing (Java)|Swing]]. The AWT is part of the [[Java Foundation Classes]] (JFC) — the standard [[Application programming interface|API]] for providing a [[graphical user interface]] (GUI) for a Java program. AWT is also the GUI toolkit for a number of [[Java Platform, Micro Edition|Java ME]] profiles. For example, [[Connected Device Configuration]] profiles require Java [[software execution|runtime]]s on [[mobile telephone]]s to support the Abstract Window Toolkit.

== History ==

When [[Sun Microsystems]] first released Java in 1995, AWT widgets provided a thin level of abstraction over the underlying native user-interface. For example, creating an AWT [[check box]] would cause AWT directly to call the underlying native subroutine that created a check box. However, athe check box on [[Microsoft Windows]] is not exactly the same as athe check box on [[Mac OSmacOS]] or on the various types of [[Unix]]. 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 native [[Apple 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.

In [[Java Platform, Standard Edition|J2SE 1.2]], the [[Swing (Java)|Swing]] toolkit largely superseded the AWT's widgets. In addition to providing a richer set of UI widgets, Swing draws its own widgets (by using [[Java 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#Look and Feel in Widget Toolkits|"look and feel"]] or a cross-platform look and feel (the "Java Look and Feel") that looks the same on all windowing systems.

Line 25:

* The ability to launch some desktop applications such as [[web browser]]s and [[Mail client|email clients]] from a Java application.

Neither AWT nor Swing areis inherently [[thread safety|thread safe]]. Therefore, code that updates the GUI or processes events should execute on the [[Event dispatching thread]]. Failure to do so may result in a [[deadlock]] or race condition. To address this problem, a utility class called [[SwingWorker]] allows applications to perform time-consuming tasks following user-interaction events in the event dispatching thread.

== Mixing AWT and Swing components ==

Line 33:

When drawing in Swing, use JPanel and override paintComponent(Graphics g) instead of using the AWT paint() methods.

Prior toBefore [[Java version history#Java SE 6|Java 6 Update 12]], mixing [[Swing (Java)|Swing]] components and basic AWT widgets often resulted in undesired side effects, with AWT widgets appearing on top of the Swing widgets regardless of their defined [[z-order]]. This problem was because the rendering architecture of the two widget toolkits was very different, despite Swing borrowing heavyweight top [[Container (data structure)#Graphic containers|containers]] from AWT.<ref>{{cite web

|url=http://java.sun.com/products/jfc/tsc/articles/mixing/index.html

|title=Mixing heavy and light components

Line 117:

|date=20 September 2009

|publisher=openjdk.java.net

|quote=''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.''

|access-date=7 March 2010

|archive-url=https://web.archive.org/web/20120319173102/http://mail.openjdk.java.net/pipermail/caciocavallo-dev/2009-September/000184.html