Abstract Window Toolkit

Source: Wikipedia, the free encyclopedia.

Windows form with some AWT examples

The Abstract Window Toolkit (AWT) is

mobile telephones
to support the Abstract Window Toolkit.

History

When

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 J2SE 1.2, the 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" or a cross-platform look and feel (the "Java Look and Feel") that looks the same on all windowing systems.

Architecture

The AWT provides two levels of

APIs
:

AWT also makes some higher level functionality available to applications, such as:

  • Access to the
    system tray
    on supporting systems; and
  • The ability to launch some desktop applications such as
    email clients
    from a Java application.

Neither AWT nor Swing is inherently 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

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.

Before

containers from AWT.[1]

Starting in Java 6 Update 12, it is possible to mix Swing and AWT widgets without having z-order problems.[2]

Example

import java.awt.*;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

public class MyApp {

    public static void main(char[] args) {
        Frame frame = new Frame("Application");
        
        frame.add(new Label("Hello!"));
        frame.setSize(500, 500);
        frame.setLocationRelativeTo(null); // Centers the window
        
        frame.addWindowListener(new WindowAdapter() {
            @Override
            public void windowClosing(WindowEvent e) {
                frame.dispose(); // Releases native screen resources
            }
        });
        
        frame.setVisible(true);
    }
}

Implementation

As the AWT is a bridge to the underlying native user-interface, its implementation on a new operating 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 an

Java2D.[5] All the necessary core-JDK modifications have since been pushed to OpenJDK 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 or DirectX), by including an external library and setting some system properties. A DirectFB backend for Caciocavallo[7] is under development, as is an HTML5 backend; the aim is to deploy existing Swing applications—without Java support—as ordinary web applications running on a web server.[7][8]

See also

References

  1. ^ Fowler, Amy (1994). "Mixing heavy and light components". Sun Microsystems. Archived from the original on 23 December 2011. Retrieved 17 December 2008.
  2. ^ "Bug/RFE fixed in current JDK 6u12 build". Sun Microsystems. 12 December 2008. Archived from the original on 17 December 2008. Retrieved 17 December 2008.
  3. ^ Torre, Mario (2 March 2008). "FINAL PROPOSAL: Portable GUI backends". Archived from the original on 19 March 2012. Retrieved 7 September 2008.
  4. ^ Kennke, Roman (18 December 2008). "Caciocavallo Architecture Overview". Retrieved 7 September 2008.
  5. ^ Kennke, Roman (3 September 2008). "Cacio Swing AWT peers". Archived from the original on 13 March 2012. Retrieved 7 September 2008.
  6. ^ "How much has been pushed upstream?". openjdk.java.net. 20 September 2009. Archived from the original on 19 March 2012. Retrieved 7 March 2010. 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.
  7. ^ a b Kennke, Roman (28 July 2011). "JDK7 and Cacio coolness". Retrieved 8 August 2011.
  8. ^ Eisserer, Clemens. "HTML5/Canvas backend for Caciocavallo (GNU-Classpath)". Archived from the original on 21 March 2012. Retrieved 8 August 2011.

External links