Java SWT, Swing or AWT

-----

SWT, Swing or AWT: Which is right for you?

What to consider when choosing a GUI tool kit for new applications

Barry Feigenbaum, Programming Adviser, IBM, Software Group

Summary:  By providing a comparison of Eclipse's SWT with the Java Swing and Abstract Windows Toolkit (AWT) GUI tool kits, this article helps developers of new applications decide which to choose. Read descriptions of each tool kit's basic features, and the pros and cons of using each.

Tag this!

Update My dW interests (Log in | What's this?)Skip to help for Update My dW interests

Date:  21 Feb 2006
Level:  Introductory

Comments:   0 (View | Add comment - Sign in)

 Average rating (613 votes)
Rate this article

Introduction

Other developerWorks authors have shown how to handle the tricky migration between Swing and SWT (see Resources). This article is intended to help you decide which GUI tool kit to choose before starting a project.

But first: Why is there more than one Java™ GUI tool kit? The best answer is that one size does not fit all, nor is there a one-size-fits-all GUI tool kit to be invented soon. Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience.

Let's learn about each of these tool kits.

Back to top

A look at AWT

Abstract Windows Toolkit (AWT) is the original Java GUI tool kit. AWT's main advantages are that it comes standard with every version of Java technology, including Java implementations in old Web browsers, and it is very stable. This means you do not need to install it, you can depend on it being available everywhere you find a Java runtime environment, and it will have the features you expect.

AWT is a very simple tool kit with limited GUI components, layout managers, and events (see Listing 1, Listing 2 and Listing 3). This is because Sun Microsystems decided to use a lowest-common denominator (LCD) approach for AWT. Only GUI components defined for all Java host environments would be used. As a result -- and unfortunately -- some commonly used components, such as Tables, Trees, Progress Bars, and others, are not supported. For applications that need more component types, you need to create them from scratch. This is a big burden.

Listing 1. The basic AWT Class tree (all in the java.awt package, "*" indicates abstract)

Object CheckboxGroup *Component Button Canvas CheckBox Choice Container Panel Applet ScrollPane Window Dialog Frame Label List TextComponent TextArea TextField MenuComponent MenuItem CheckboxMenuItem Menu PopupMenu

NOTE: Other AWT components exist in several other packages, but this is the basic set.

Listing 2. AWT provides the following layout managers (all in the java.awt package, "*" indicates interface)

*LayoutManager FlowLayout GridLayout *LayoutManager2 BorderLayout CardLayout GridBagLayout

NOTE: Other AWT layout managers exist in several other packages, and many are specialized to the container they lay out, but this is the basic set.

Listing 3. AWT provides the following events (most in the java.awt.events package)

Object EventObject AWTEvent ActionEvent AdjustmentEvent ComponentEvent ContainerEvent FocusEvent InputEvent KeyEvent MouseEvent MouseWheelEvent PaintEvent WindowEvent HierarchyEvent InputMethodEvent InvocationEvent ItemEvent TextEvent

NOTE: Other AWT events exist in several other packages, but this is the basic set. These are specific events generated from a more generic event.

In general for AWT (and also Swing and SWT), each event type has an associated XxxListener interface (and possiblyXxxAdapter null implementation), where Xxx is the event without the Event suffix (for example, KeyListener for a KeyEvent), which is used to pass the events to handlers. Applications register with the event source (the GUI component or widget) for the events they are interested in processing. Some listeners handle multiple events.

One nice feature of AWT is that it, in general, supports automatic disposal of GUI components. This means that you rarely need to dispose components. The exception is high-level components, such as Dialogs and Frames. If you create resources that consume significant host resources, you can dispose of them manually.

AWT components are thread-safe, which means you do not need to be concerned as to which thread in your application updates the GUI. This can eliminate many GUI update problems, but can make AWT GUIs run slower.

AWT allows you to build GUIs top-down or bottom-up or in any combination. By top-down, I mean creating a container component before any of its children. By bottom-up, I mean creating children before creating their containing (or parent) component. Thus, a component can exist without a parent container, and its parent can change over time.

AWT GUIs, in general, are not accessible. There is no API for an AWT programmer to specify accessibility information. Accessibility deals with how well an application can be used by people with disabilities. To be accessible an application, together with the platform it runs on, must enable PwDs to use the application with the appropriate assistive technologies (tools that provide alternate user interfaces). Many governments and corporations have standards that require applications to be enabled for accessibility.

Sun wanted the Java language to be a "write once, run everywhere" (WORE) environment. This means Java code could be developed and tested on one host (Windows®, for example) and be expected to run the same on any other Java host without testing. For the most part, Java technology succeeded, but AWT was a weak spot. Because AWT depended on host GUI peercontrols (where each AWT component has a parallel host control or peer) to implement the GUI, the GUI looked and -- more importantly -- behaved differently on different hosts. This resulted in a "write once, test everywhere" (WOTE) situation, which was less than satisfactory.

AWT provides a rich graphics environment, especially in Java V1.2 and beyond. Through the Graphics2D object, and Java2D andJava3D services, many powerful graphical applications, such as drawing and charting packages and, combined withJavaSound, competitive interactive games, can be created.

Back to top

A look at Swing

Java Swing, also known as a part of the Java Foundation Classes (JFC), was an attempt to solve most of AWT's shortcomings. In Swing, Sun created a very well-engineered, flexible, powerful GUI tool kit. Unfortunately, this means Swing takes time to learn, and it is sometimes too complex for common situations.

Swing is built on parts of AWT. All Swing parts are also AWT parts. Swing uses the AWT event model and support classes, such as Colors, Images, and Graphics. The Swing components, layout managers, and events are summarized below (see Listing 4,Listing 5 and Listing 6). As you can see, these sets are far more extensive than that supplied by AWT and compares well to the SWT set.

Listing 4. The basic Swing Class tree (all in the javax.swing package or subpackage, "*" indicates an abstract class)

Object *Component Container *JComponent *AbstractButton JButton JMenuItem JCheckBonMenuItem JMenu JRadioButonMenuItem *JToggleButton JCheckBox JRadioButton Box Filler JColorChooser JComboBox JDesktopIcon JFileChooser JInternalFrame JLabel JLayeredPane JDesktopPane JList JMenuBar JOptionPane JPanel JPopupMenu JProgressBar JRootPane JScrollBar JScrollPane JSeparator JSlider JSplitPane JTabbedPane JTable JTableHeader *JTextComponent JEditorPane FrameEditorPane JTextPane JTextArea JtextField JPasswordField JToolBar JToolTip JTree JViewport ScrollableTabViewport Panel Applet JApplet Window Dialog JDialog Frame JFrame JWindow

NOTE: Many other Swing components exist, in several other packages, but this is the basic set.

Listing 5. Swing provides the following additional LayoutManagers (all in the javax.swing package or subpackages, "*" indicates interface)

*LayoutManager CenterLayout *LayoutManager2 BoxLayout OverlayLayout SpringLayout

NOTE: Many other Swing layout managers exist in several other packages, and many are specialized to the container they lay out, but this is the basic set.

Listing 6. Swing provides additional events (most in the javax.swing.events package and subpackages)

Object EventObject AWTEvent AncestorEvent ComponentEvent InputEvent KeyEvent MenuKeyEvent MouseEvent MenuDragMouseEvent InternalFrameEvent

NOTE: Other AWT events exist in several other packages, but this is the basic set. These are "high-level" events generated from a more generic event.

To overcome the variation in behavior across different hosts, Swing minimized its dependence on host controls. In fact, Swing uses peers for only top-level components like windows and frames. Most components (JComponent and its subclasses) are emulated in pure-Java code. This means that Swing is naturally portable across all hosts. Thus, Swing does not typically look like a native application. In fact, it has multiple looks, some that can emulate -- although often not exactly -- different hosts and some that provide unique looks.

Swing uses the term heavyweight for peer-based components and lightweight for emulated components. In fact, Swing supports mixed heavy and light components in a single GUI, such as mixing AWT and Swing controls in the same JContainer, but care must be taken with drawing order if the components overlay each other.

Swing may not be able to take advantage of hardware GUI accelerators and special host GUI operations. As a result, Swing applications may be slower than native GUIs. Sun has worked hard on the performance of the recent versions of Swing (Java V1.4 and 1.5), and this disadvantage is becoming less noticeable. Because Swing's design is more robust, its code base is larger. This can mean it takes a beefier machine to run it than AWT or SWT might.

Beyond more components, layout mangers, and events, Swing has many features that make it more powerful than AWT. Some of the more important ones are:

Separation of model from the view and controller

For all components with models (such as buttons, lists, tables, trees, rich text), the model is separate from the component. This allows the model to be adapted to the needs of the application and for it to be shared by multiple views. Default models per component type are provided for convenience.

Programmable look and feel

Each component's look (appearance) and feel (how it reacts to input events) is controlled by a separate and dynamically replaceable implementation. This allows the look and feel of all or part of a Swing-based GUI to change.

Renderers and editors

Most components that show model content, such as lists, tables, and trees, can process model elements of almost any type. This is done by mapping a renderer or editor for each component type and model type. For example, a table with a column containing java.util.Date values can have special code to present the date value and edit the date value. Each column can have different types.

Accessibility

Creating a GUI that is accessible to people with disabilities is important. Swing offers an extensive infrastructure and API for enabling GUIs for accessibility. This support is independent of but integrates with the host accessibility support, if any.

Like AWT, Swing supports automatic disposal of GUI components. Swing also supports the AWT bottom-up and top-down construction methods.

Unlike AWT, Swing components are not thread-safe, which means you need to be concerned as to which thread in your application updates the GUI. If you err in thread use, unpredictable behavior, including user interface glitches, can occur. Utility routines exist to help manage threading issues.

Like AWT, one of Swing's advantages is that it comes standard with Java technology. This means you do not need to install it. Unfortunately, Swing has evolved a lot, so it is easy to become dependent on features provided in more recent versions of the Java language, which may force users to upgrade their Java runtimes.

Back to top

A look at SWT

SWT is a low-level GUI tool kit comparable in concept to AWT. JFace is a set of enhanced components and utility services to make building GUIs with SWT easier. The builders of SWT learned from the AWT and Swing implementations and tried to build a system that had the advantages of both without their disadvantages. In many ways, they succeeded.

SWT is a lot like AWT in that it is based on a peer implementation. It overcomes the LCD problem faced by AWT by defining a set of controls adequate to make most office applications or developer tools and then, on a host-by-host basis, creating emulated (like Swing) controls for any not supplied by the particular host. For most modern hosts, nearly all the controls are based on native peers. This means that an SWT-based GUI has a host look and feel, and host performance. This avoids the most widely held complaints with AWT and Swing. Certain hosts have low-function controls, so SWT supplies extended, often emulated, versions (often with "C" as the first letter in their names) to allow the more generally expected behavior.

SWT is different from AWT in how the peers work. In SWT, the peers are just wrappers on host controls. In AWT, peers can provide services to minimize the differences between hosts (this is where AWT ran into a lot of its behavior issues). This means that an SWT application is really a host application, with all the good and bad points that entails. It also means that SWT does not fully achieve the WORE goal; it is more a WOTE solution. That said, SWT does a remarkable job of creating a portable solution, albeit not as well as Swing.

The SWT widgets, layouts, and events are summarized below (see Listing 7, Listing 8 and Listing 9). As you can see, these sets are far more extensive than that supplied by AWT and compares well to the Swing set.

Listing 7. The basic SWT Class tree (most in the org.ecipse.swt.widgets or org.eclipse.swt.custom package or subpackages, "*" indicates an abstract class, "!" in custom package, "~" some other package)

Object *Dialog ColorDialog DirectoryDialog FileDialog FontDialog MessageDialog PrintDialog *Widget Menu *Item CoolItem !CTabItem MenuItem TabItem TableColumn TableItem TableTreeItem ToolItem TrayItem TreeColumn TreeItem *Control Button Label ProgressBar Sash Scale Scrollable Composite ~Browser Canvas *~AbstractHyperlink ~Hyperlink ~ImageHyperlink *~ToggleHyperline ~TreeNode ~Twistie AnimatedProgress !CLabel Decorations Shell FormText StyledText TableCursor !CBanner !CCombo Combo CoolBar !CTabFolder ~ExpandableComposite ~Section ~FilteredList ~FilteredTree ~Form Group ~PageBook ProgressIndicator !SashForm !ScrolledComposite TabFolder Table TableTree ToolBar Tray Tree ViewForm List Text Slider

NOTE: Many other SWT widgets exist in several other packages, but this is the basic set.

Like AWT and Swing layout managers, SWT provides a comprehensive set of layouts. Both layout systems, combined with nested containers, can generate almost any needed layout algorithm. All three GUI libraries also support absolute control positioning. The lack of a SWT BorderLayout equivalent is disappointing. The FormLayout is very nice for creating form-base input. I think the SWT layout scheme is a little harder to learn to use than the AWT/Swing set.

Listing 8. SWT provides the following layout managers (most in the org.eclipse.swt.layout org.eclipse.swt.custom package or subpackages, "*" indicates interface, "!" in custom package)

*Layout FillLayout FormLayout GridLayout RowLayout !StackLayout

NOTE: Other SWT layout managers exist in several other packages, and many are specialized to the container they lay out, but this is the basic set.

Like the AWT and Swing event systems, SWT provides a comprehensive set of events. Although the events are not one-to-one with AWT/Swing (for example, AWT and Swing buttons both fire ActionEvent while SWT buttons fire SelectionEvent), they are generally equivalent.

Listing 9. SWT provides the following events (most in the org.eclipse.swt.events package or org.eclipse.swt.custom package or subpackages, "*" indicates abstract, "!" in custom package)

Object EventObject SWTEventObject TypedEvent AimEvent !BidiSegmentEvent ControlEvent !CTabFlolderEvent DisposeEvent DragSourceEvent DragTargetEvent !ExtendedModifyEvent focusEvent HelpEvent KeyEvent TraverseEvent VerifyEvent !LineBackgroundEvent !LineStyleEvent MenuEvent ModifyEvent MouseEvent PaintEvent SelectionEvent TreeEvent ShellEvent !TextChangedEvent !TextChangingEvent

NOTE: Other SWT events exist in several other packages, but this is the basic set. These are specific events generated from a more generic event.

Many Swing components, such as JTable, have models. SWT control equivalents (such as Table) do not; they have items, instead. Items are generally limited to showing text or generally small images (such as icons). To provide a Swing-like model structure, JFace ContentProviders are used. These providers act as a bridge between the application-supplied model (such as ajava.util.Array for a List or Table), and the control acting as the view. In order to format arbitrary model objects into items, SWT uses JFace LabelProviders, which generate a text or iconic form for any model object. This can limit the sophistication of the display of complex model objects. Other providers, such as ColorProviders and LabelDecorators, can enhance the display of items. For the special case of Tables, SWT provide a CellEditor that temporarily links an arbitrary SWT control to a Table cell to act as an editor for that cell.

SWT does not support automatic disposal of GUI controls. This means that you must explicitly dispose of any controls or resources, such as colors or fonts, you create, as opposed to getting from an API call. This effort is eased somewhat as container controls dispose of their child controls automatically.

SWT only allows you to build GUIs top-down. Thus, a control cannot exist without a parent container, and its parent cannot, in general, change over time. This approach is much less flexible than AWT/Swing. Controls are added to a parent container during creation and removed when disposed. Also, the SWT use of style bits only at construction time can limit the flexibility of some GUI controls. Many styles are hints only and do not work the same on all platforms.

Like Swing, SWT components are not thread-safe, which means you need to be concerned about which thread in your application updates the GUI. If you err in thread use an exception is thrown. I think this is better than the non-deterministic Swing approach. Special utility routines exist to help manage threading issues.

SWT GUIs are generally accessible if the supporting host provides accessibility services. SWT provides a basic out-of-process API for programmers to specify accessibility information when the default information is inadequate.

SWT provides a limited graphics environment. To date, it does not compare well to the support of Java2D and Java3D. Eclipse provides a separate feature called Graphical Editing Framework (GEF) with a component called Draw2D that can be used to create some drawing applications, such as UML modeling tools. Unfortunately, GEF is difficult to use stand-alone (meaning outside the entire Eclipse environment).

Unlike AWT and Swing, SWT and JFace do not come with Java technology. They must be installed separately, as part of an Eclipse installation or as separate libraries. The Eclipse team has made it fairly easy to install and run SWT independently of Eclipse. The needed Java archives (JAR) and Dynamic Link Libraries (DLL), and similar libraries for UNIX® and Macintosh can be downloaded separately from the Eclipse Web site. The JFace libraries require you to download all of Eclipse and copy out the needed JARs. Once downloaded, the JARs need to be on the Java CLASSPATH and the DLLs on the system PATH.

Back to top

Feature comparison

The following table compares, in no particular order, many characteristics of the AWT, SWT, and Swing libraries. This list is not exhaustive, but covers the most important characteristics.

Table 1. SWT vs. AWT and Swing Feature comparison

Function/Role/Aspect	AWT	Swing	SWT (style)
Display static text	Label	JLabel	Label, CLabel
Display multi-line static text	Multiple Labels	Multiple JLabels or JLabel with HTML content	Multiple Labels or Label with newlines
Display multi-line formatted static text	Multiple Labels with different fonts	JLabel with HTML content	Multiple Labels with different fonts
Single-line text entry	TextField	JTextField	Text(SWT.SINGLE)
Multi-line text entry	TextArea	JTextArea	Text(SWT.MULTI)
Display an image	N/A	JLabel	Label
Display text and image	N/A	JLabel	CLabel
ToolTip pop-up help	N/A	setToolTip on component, subclass JToolTip	setToolTip on control
Styled text entry	N/A	JEditorPane	StyledText
Select from list of items	List	JList	List
Simple push button with text	Button	JButton	Button(SWT.PUSH)
Simple push button with text and/or image	N/A	JButton	Button(SWT.PUSH)
Drawing area; possibly for custom controls	Canvas	JPanel	Canvas
On/off check box	CheckBox	JCheckBox	Button(SWT.CHECK)
Radio selection	CheckBoxGroup	ButtonGroup and menus	Group and Menu
Select from a drop-down list	Choice	JComboBox	Combo, CCombo
Enter text or select from a drop-down list	N/A	JComboBox	Combo, CCombo
Scrollable area	ScrollPane	JScrollPane	Create Scrollable subclass
Top level windows	Dialog, Frame, Window	JDialog, JFrame, JWindow	Shell with different styles
Generic window	Window	JWindow	Shell
Frame window	Frame	JFrame	Shell(SWT.SHELL_TRIM)
Dialog window	Dialog	JDialog	Shell(SWT.DIALOG_TRIM)
Menu	Menu	JMenu	Menu
MenuItem	MenuItem	JMenuItem	MenuItem
Menu shortcuts	Generic keystrokes	same as AWT	host dependent mnemonics and accelerators
Pop-up menu	PopupMenu	JPopupMenu	Menu(SWT.POPUP)
Menu bars	MenuBar	JMenuBar	Menu(SWT.BAR)
Display an insertion caret	N/A	Caret	Caret
Web browser	N/A	JTextPane (HTML 3.2)	Browser (via embedded browser)
Embed control in web page	Applet	JApplet	Host control (ex. OLE)
Generic container of other controls	Panel	JPanel	Composite
Generic container of other controls with a border	Panel (if drawn manually)	JPanel with a Border	Composite(SWT.BORDER)
Generic container of other controls with a border and title	N/A	JPanel with a TitledBorder	Group
Radio button (one of set on)	Checkbox	JRadioButton	Button(SWT.RADIO)
Control extent of radio buttons	CheckboxGroup	RadioButtonGroup	Group
Arrow buttons	N/A	JButton with image	Button(SWT.ARROW)
Supports int'l text orientations	via ComponentOrientation	same as AWT	Many components support styles for this
Focus Traversal	Policy and Manager objects	same as AWT	Next on control
Custom dialogs	Dialog subclass	JDialog subclass	Dialog subclass
Access to system events	EventQueue services	same as AWT	Display services (less robust than AWT)
System access dialogs	FileDialog	JColorChooser, JFileChooser	ColorDialog, DirectoryDialog, FileDialog, FontDialog, PrintDialog
Display simple message dialog	N/A (must subclass Dialog)	JOptionPane static methods	MessageBox with numerous styles
Display simple prompting dialog	N/A (must subclass Dialog)	JOptionPane static methods	N/A (classes exist in JFace to do this)
Layout managers	BorderLayout, CardLayout, FlowLayout, GridLayout, GridBagLayout	AWT plus BoxLayout, CenterLayout, SpringLayout	FillLayout, FormLayout, GridLayout, RowLayout, StackLayout
Basic drawing control	Canvas	JPanel	Canvas
Basic drawing	Graphics and Graphics2D objects - Basic shapes and text, arbitrary Shapes and Strokes, Bezier, fills, etc.	same as AWT	GC object - Basic shapes and text
Drawing transforms	Affine, composites	same as AWT	N/A
Off screen drawing	BufferedImage, drawImage	same as AWT	Image, drawImage
Double buffering	Manual	Automatic or manual	Manual unless provided by host control
Printing	PrintJob and PrintGraphics	same as AWT	draw to Printer device
Custom colors	Color	same as AWT	Color
Custom fonts	Font, FontMetrics	same as AWT	Font
Cursors selection	Cursor	same as AWT	Cursor
Image features	load from file, create dynamically, extensive edits	same as AWT	load from file, create dynamically, basic edits
Input automation	Robot	same as AWT	N/A
Display a tool bar	N/A	JToolBar	ToolBar, CoolBar
Display a progress bar	N/A	JProgressBar	ProgressBar
Divide space between areas	N/A	JSplitPane	Sash or SashForm
Display tabbed areas	N/A	JTabbedPane	TabFolder, CTabFolder
Display tabular info	N/A	JTable	Table
Format table columns	N/A	TableColumn	TableColumn
Display hierarchical info	N/A	JTree	Tree
Select from range of values	N/A	JSlider	Slider
Select from discrete range of values	N/A	JSpinner	Scale
Access to the base display	Toolkit, GraphicsConfiguration, GraphicsDevice	same as AWT	Display
Add items to the system tray	N/A	N/A	Tray
Key: N/A - Not available. In many cases, this feature can be created, with varying degrees of difficulty, by creating custom controls or containers of controls or by other custom programming.

Back to top

Conclusion

This article provided a comparison between the Eclipse's Standard Windows Toolkit with JFace, and the Java's Swing and Abstract Windows Toolkit GUI tool kits. Through the comparisons provided here, you can decide which GUI tool kit to use for your new applications.

In most cases, the decision is between Swing and SWT combined with JFace. In general, each of these tool kits is complete and powerful enough to build full-function GUIs, but Swing is generally superior to SWT alone (used without JFace). Swing has the advantage of being built into Java technology, is completely portable, and arguably has a better architecture. Swing also has the advantage for advanced graphical applications. SWT has the advantage of being implemented as a native application which increases the performance and native compatibility of SWT-based GUIs.

If you are developing only for one platform, SWT has an advantage in host compatibility, including integration with host features, such as use of ActiveX controls under Windows.

Resources

Learn

• For migration of Swing to SWT, see the developerWorks tutorial "Migrate your Swing application to SWT."
• For using SWT/JFace outside of Eclipse, see the series of developerWorks articles starting with "Using the Eclipse GUI outside the Eclipse Workbench, Part 1."
• Learn more about AWT from Sun's AWT package summary documentation.
• Learn more about Swing from Sun's Swing package summary documentation. See also The Swing Connection, the Swing news page, and the tutorial Creating a GUI with JFC/Swing. For an on-line book, see O'Reilly's Java Foundation Classes in a Nutshell.
• If you're new to SWT and JFace, check out the developerWorks series "A gentle introduction to SWT and JFace," which is about creating simple SWT applications.
• Visit developerWorks' Eclipse project resources to learn more about Eclipse.
• Stay current with developerWorks technical events and webcasts.
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.

Get products and technologies

• Get Cogito and the Linux® kernel source at The Linux Kernel Archives.
• Innovate your next open source development project with IBM trial software, available for download or on DVD.

Discuss

• Get involved in the developerWorks community by participating in developerWorks blogs.

About the author

Barry Feigenbaum, Ph.D., is a member of the IBM Worldwide Accessibility Center, which helps IBM make its products accessible to people with disabilities. He has published several books and articles, holds several patents, and has spoken at industry conferences, such as JavaOne. He has served as an adjunct assistant professor of computer science at the University of Texas at Austin and other schools.

-----
copied from: http://www.ibm.com/developerworks/grid/library/os-swingswt/