AWT and Swing comparison

The AWT toolkit came with the initial release of Java. On the other hand, Swing was only released with Java 1.2. In order to keep backwards compatibility, Swing builds on top of AWT and all the old widgets are maintained. Many of them like components, containers, panels, windows, dialogs, and frames are inherited from by Swing components.

Swing represents a radically different way of doing GUIs then AWT with a model/view architecture, pluggable looks and feels, integrated accessibility, lightweight components, etc. It is not enough to simply change the functionality of existing AWT widgets like Buttons, entirely new widgets had to be built. Typically, they are distinguished from their AWT counterparts by a J prefix.

This means that there are different versions of the same component in Java SE like Button and JButton, the first of which is a part of AWT and the later of which is a part of Swing. In a couple of cases there are subtle differences in spelling like between Checkbox in AWT and JCheckBox in Swing, which uses different capitalisation then its AWT counterpart. The following tables distinguish between AWT and Swing components.

The newer GUI toolkit, JavaFX, doesn't have these distinctions. JavaFX may very well be the future of GUIs. It has an excellent scene graph library and a cleaner API design so it is worth checking out. Of course, Swing is still excellent and holds up quite well to everything today despite its age it just lacks the advanced graphical capabilities of JavaFX.

Components comparison

Elements
There is no corresponding Canvas component in Swing, so if you want that functionality you should look in to creating your own custom JComponents. Everything you could do with Canvas can instead be done this way. AWT Choices are called combo boxes instead in Swing.

AWT	Swing
Button	JButton
Canvas	JComponent
Checkbox	JCheckBox
Choice	JComboBox
Label	JLabel
List	JList
Scrollbar	JScrollBar
TextComponent	JTextComponent
TextArea	JTextArea
TextField	JTextField

Containers
Every single Swing component is a Container. The JComponent class subclasses the AWT Container class, and all the other Swing components do as well. On the other hand, not every AWT component is a Container, so we describe how those that are can be converted to Swing.

AWT	Swing
Panel	JPanel
Applet	JApplet
ScrollPane	JScrollPane
Window	JWindow
Dialog	JDialog
FileDialog	JFileChooser
Frame	JFrame

Menus
AWT menus can be readily translated into Swing menus. One technical difference is that AWT menu items are not Components. In Swing every menu component is a JComponent, so this produces a cleaner architecture.

AWT	Swing
MenuComponent	JComponent
MenuBar	JMenuBar
MenuItem	JMenuItem
CheckboxMenuItem	JCheckBoxMenuItem
Menu	JMenu
PopupMenu	JPopupMenu

New components

With the AWT and Swing comparison, we can now identify which components introduced by Swing are genuinely new and not part of some older toolkit.

• slider
• spinner
• progress bar
• radio button
• color chooser
• split pane
• tabbed pane
• table
• editor pane
• tree
• tooltip
• toolbar
• viewport
• box
• internal frame
• layered pane
• option pane
• root pane

As you can see by this fairly long list there is quite a lot that is in Swing that has no counterpart in AWT. It is a genuinely new and more modern toolkit then AWT, with probably twice as many widgets. With this many widgets, Swing still holds up pretty well to its counterparts like QT.

New layout managers

As Swing descends from AWT, it still basically uses its layout managers most of the time: GridLayout, CardLayout, GridBagLayout, FlowLayout, and BorderLayout. These suffice for most things, but Swing introduces a number of layout managers which operate alongside their AWT counterparts:

• Box layout
• Overlay layout
• Spring layout
• Group layout

In terms of the comparison between AWT and Swing, we see that unlike for components these are not a replacement for AWT layout managers they are merely extensions of them. Your applications still going to want to use AWT layout managers, except now you want to use Swing ones as well in some cases.

New events

In Java 1.0 there was only the Event class of the AWT package. This was the original Event class in the Java platform. All event handling was done by subclassing, so that a given class would handle events by overriding the handleEvent method. This naturally wasn't a very extensible approach, as objects couldn't listen to events of other objects. Java 1.1 fixed this by introducing the AWT 1.1 event model which is based upon listeners and the AWTEvent class.

The Swing event system builds upon the AWT 1.1 event model. Swing introduces a number of new subclasses of AWTEvent for its components, and listeners that can be registered for them. At the same time, it also introduces a great many new events that aren't AWTEvents as a consequence of its new model/view approach. These events let you listen to changes in the underlying model rather then in the view. All the technical details are in the javax.swing.event package.

External links:
Java desktop module