For standalone Java desktop application, developers have two main options. You can use Java Swing, built into the JDK, or you can use the Standard Widget Toolkit (SWT) from Eclipse. Both approaches share some commonality, but each has its own advantages and methods. This DZone Refcard provides a reference on how to use both technologies; the first half of the Refcard will cover Swing, with SWT forming the second half.

Before Swing, the only option that Java GUI developers had was to use AWT (Abstract Widget Toolkit). However, because of limitations in AWT, such as the number of components and portability issues, Sun introduced Swing. Swing is built on AWT components, and also uses its event model. While AWT provides heavyweight components, Swing provides lightweight components and adds advanced controls such as tables because it does not require the use of native resources within the operating system.

All Swing components are derived from JComponent, which deals with the pluggable look & feel, keystroke handling, action object, borders and accessibility.

A typical Swing application will consist of a main window, with a menu-bar, toolbar and contents. The main shell for the application is represented as a JFrame. Within the JFrame, an instance of JRootPane acts as a container for all other components in the frame.

Figure 1: The structure of a JFrame

The root pane has four parts:

The glass pane

The glass pane is hidden by default. If it is made visible, then it’s like a sheet of glass over all the other parts of the root pane. It’s completely transparent unless you implement the glass pane’s paintComponent method so that it does something, and it can intercept input events for the root pane.

The layered pane

The layered pane positions its contents, which consist of the content pane and the optional menu bar. Can also hold other components in a specified Z order, as illustrated in Figure 2.

The content pane

The content pane is the container of the root pane’s visible components, excluding the menu bar.

The optional menu bar

If the container has a menu bar, you generally use the container’s setJMenuBar method to put the menu bar in the appropriate place.

Figure 2: Layer order in layered pane

javax.swing.JFrame

JFrame is the main window component of any Swing application. To create an application window, you just need to create a class that extends JFrame.

public class SwingApp extends JFrame
{
  public SwingApp(String title)
  {
    super(title);
    setSize(400, 400);
   }
}

Figure 3: A Swing JFrame

javax.swing.JApplet

JApplet allows the addition of menus and toolbars to applets hosted in a browser. Since Java 6 Update 10, applets can also be dragged outside of the browser to run on the desktop.

Construction code for applets go into the init() method, rather than the applets constructor.

public class SwingApplet extends JApplet {
public SwingApplet()
{}
public void init()
{
setSize(100, 100);
}
}

All layout managers implement one of two interfaces: java. awt.LayoutManager or its subclass, java.awt.LayoutManager2. LayoutManager provides methods that give a straight-forward, organized means of managing component positions and sizes in a container. LayoutManager2 enhances this by adding methods intended to aid in managing component positions and sizes using constraints-based objects. Constraints-based objects store position and sizing information about one component and implementations of LayoutManager2 normally store one constraints-based object per component.

java.awt.FlowLayout

A flow layout arranges components in a directional flow one after the other, moving onto a new line when no more components fit on the current line. Direction is determined by the container’s componentOrientation property and may be one of two values: ComponentOrientation.LEFT_TO_RIGHT or ComponentOrientation.RIGHT_TO_LEFT

Flow layout is the default layout manager for AWT and
Swing components.

java.awt.GridLayout

GridLayout lays out a container’s components in a rectangular grid. The container is divided into equal-sized rectangles, and one component is placed in each rectangle. Typically, a GridLayout is constructed by specifying the number of rows and columns.

java.awt.BorderLayout

BorderLayout lays out the components in five regions: NORTH, SOUTH, EAST, WEST and CENTER. As each component is added to a container with a border layout, the location is specified similar to: container.add(component, BorderLayout.CENTER);

java.awt.CardLayout

CardLayout acts as an organisation of stacked components on a container, with only one card being visible at a time. The first component added is the visible component when the container is first displayed. Methods exist to go through the stack sequentially or to access a particular card.

javax.swing.BoxLayout

BoxLayout allows multiple components to be laid out vertically (Y_AXIS) or horizontally (X_AXIS). Components do not wrap, so when the frame is resized the components remain in their initial arrangement. Components are arranged in the order that they are added to the layout manager.

java.awt.GridBagLayout

GridBagLayout is the most flexible layout manager, maintaining a dynamic, rectangular grid of cells. Each component can occupy one or more cells, and has an instance of GridBagConstraints to specify how a component should be displayed in its display area.

The following table illustrates the options in GridBagConstraints:

Standard click events on Swing components are handled using the java.awt.event.ActionListener interface. Implemented action handlers need to implement the public voidactionPerformed(ActionEvent e), provided the component has registered the action listener using the addActionListener() method.

Three interfaces are provided to handle mouse events on components:

Alternatively, you can extend the java.awt.event.MouseAdapter class, which packages all three interfaces into a single abstract class to make it easier to handle particular mouse events.

Attaching Mouse Listeners

Mouse listeners can be added to your component by simply using the appropriate method (addMouseListener, addMouseWheelListener, addMouseMotionListener).

Time consuming tasks should not be run on the event dispatch thread, as this will cause the application to become unresponsive. Additionally, any components accessed should only be accessed through the event dispatch thread.

SwingWorker is designed for situations where you need to have a long running task run in a background thread and provide updates to the UI either when done, or while processing. Subclasses of SwingWorker must implement the doInBackground() method to perform background computation.

The Standard Widget Toolkit (SWT) is a widget toolkit that provides both a portable API and tight integration with the underlying native OS GUI platform. SWT defines a common API provided on all supported platforms, allowing the toolkit to take on the look & feel of the underlying native widgets. JFace provides a higher level abstraction over SWT, in a similar way to Swing and AWT. However, most controls are available in SWT, with JFace providing viewers and actions.

A stand-alone SWT application has the following structure:

• A Display which represents an SWT session.
• A Shell that serves as the main window for the application.
• Other widgets that are needed inside the shell.

In order to create a shell, you need to run the event dispatch loop continuously until an exit condition occurs, i.e. the shell is closed. Following this event the display must be disposed.

public static void main (String [] args) {
   Display display = new Display ();
   Shell shell = new Shell (display);
   //create SWT widgets on the shell
   shell.open ();
   while (!shell.isDisposed ()) {
     if (!display.readAndDispatch ()) display.sleep ();
   }
display.dispose ();
}

The Display provides a connection between SWT and the platform’s GUI system. Displays are used to manage the event dispatch loop and also control communication between the UI thread and other threads.

The Shell is a “window” managed by the OS platform window manager. Top level shells are those that are created as a child of the display. These windows are the windows that users move, resize, minimize, and maximize while using the application. Secondary shells also exist, such as dialogs – these are created as the child of other shells.

Any widget that is not a top level shell must have a parent shell or composite. Composite widgets are widgets that can have children. In SWT the Shell is the root of a widget hierarchy.

org.eclipse.swt.widgets.Shell

The Shell is the main window, and parent container of all other widgets in an SWT application.

org.eclipse.swt.widgets.Composite

The Composite is a widget that can contain other composites or controls, similar to a JPanel in Swing. Composite is the super class of all composites, and can also be used directly.

org.eclipse.swt.widgets.Dialog

SWT also provides a Dialog class, which should be modal with a Shell as its parent.

Just as in Swing, SWT provides a number of core layout managers, as well as providing the opportunity to create your own custom layout from the org.eclipse.swt.layout.Layout base class.

org.eclipse.swt.layout.FillLayout
FillLayout lays all widgets in a single continuous row or column. All widgets are forced to be the same size in this layout. Unlike Swing’s FlowLayout, FillLayout does not wrap, but you can specify margins and spacing. FillLayout is useful when a Composite only has one child, as it can cause the child of the composite to fill the shell.

FillLayout fillLayout = new FillLayout(SWT.VERTICAL); shell.setLayout(fillLayout);

org.eclipse.swt.layout.RowLayout
RowLayout places components in horizontal rows or vertical columns within the parent Composite. Unlike FillLayout, RowLayout allows components to wrap and also provides margins and spacing. Rather than all components being the same size, each control can have its own parameters using the RowData object. A control can use this object through its setLayoutData method.

org.eclipse.swt.layout.GridLayout
The most flexible layout manager in SWT is GridLayout, which lays components out in a grid formation. Each control that is placedin a composite using this layout can have an associated GridData object which configures the control. A control can use a GridData object through it’s setLayoutData method.

Note: GridData objects should not be reused between widgets, as it must be unique for each widget.

A grid can have a number of columns associated with it. As widgets are added they are laid out in the columns from left to right. A new row is created when the previous row has been filled. The following table illustrates the options in GridData:

org.eclipse.swt.layout.FormLayout
FormLayout positions children of a composite control by using FormAttachments to optionally configure the left, top, right and bottom edges of each child. Each child of a composite using FormLayout needs to have a FormData object with a FormAttachment.

Each side of a child control can be attached to a position in the parent composite, or to other controls within the Composite by creating instances of FormAttachment and setting them into the top, bottom, left, and right fields of the child’s FormData. If a side is not given an attachment, it is defined as not being attached to anything, causing the child to remain at its preferred size.

If a child is given no attachment on either the left or the right or top or bottom, it is automatically attached to the left and top of the composite respectively.

SWT provides two ways of handling events: using the built in typed listeners, or using un-typed listeners which provides a framework for you to create your own listeners.

Un-typed Listeners
Creating un-typed listeners in SWT involves three classes from the org.eclipse.swt.widgets package:

The addListener method accepts an eventType method. The following table lists out the possible values for this field:

In order to keep the UI as responsive as possible, any long running operations triggered by a UI event should be run in a separate thread. The application program runs the event loop in its main thread and dispatches events directly from this thread. The UI thread is the thread in which the Display was created. All other widgets must be created in the UI thread.

Applications that wish to call UI code from a non-UI thread must provide a Runnable that calls the UI code. The methods syncExec(Runnable) and asyncExec(Runnable) in the Display class are used to execute these runnables in the UI thread during the event loop.

• syncExec(Runnable)should be used when the application code in the non-UI thread depends on the return value from the UI code or otherwise needs to ensure that the runnable is run to completion before returning to the thread. SWT will block the calling thread until the runnable has been run from the application’s UI thread.
• asyncExec(Runnable) should be used when the application needs to perform some UI operations, but is not dependent upon the operations being completed before continuing.