Questions tagged [swt-awt]

swt-awt stands for a bridge developed with a goal to make SWING and SWT applications coexist in the same application.

Introduction

Swing and SWT are sometimes seen as strictly competing technologies. Some people have strong opinions on which UI toolkit to use exclusively for client applications. However, in the real world, ideological extremes are often impractical. Some valid use cases require both technologies to coexist in a single application. While mixing the two toolkits is not a simple task, it can be done, and it can be done such that the two toolkits are smoothly integrated. This article discusses the steps necessary to achieve good Swing/SWT integration. It focuses on the use case of embedding existing Swing components into an SWT-based Rich Client Platform application.
(By Gordon Hirsch, SAS Institute Inc. Copyright © 2007 SAS Institute Inc. Made available under the EPL v1.0 June 20, 2007)

Using the SWT/AWT Bridge

The SWT/AWT Bridge has been part of SWT since version 3.0. It is a very simple API, located in the package org.eclipse.swt.awt. [Note]

This article focuses on embedding AWT frames inside SWT composites. It demonstrates only one half of the SWT/AWT Bridge. Nevertheless, most of the improvements described below also apply to the other direction: embedding SWT composites inside AWT frames.

Minimally, embedding an AWT frame inside an SWT composite is just two simple lines of code

Composite composite = new Composite(parent, SWT.EMBEDDED | SWT.NO_BACKGROUND);
Frame frame = SWT_AWT.new_Frame(composite);

An instance of org.eclipse.swt.Composite is created with the SWT.EMBEDDED style. This style signals that an AWT frame is to be embedded inside the Composite. The call to the static new_Frame method creates and returns such a frame. The frame may then be populated with AWT and/or Swing components.

The returned frame is not a standard AWT frame. By default, it is a subclass of java.awt.Frame that is meant to be embedded within native applications. In fact, it is the same frame that is used to embed applets inside a browser window.

The example code shown above is deceptively simple. While SWT does much under the covers to manage the integration of the two toolkits, the scope of the bridge's implementation is very narrow. In reality, you must do much more in your application to make the integration more consistent

Multiple Event Threads

Swing/SWT integration has important threading implications. Each UI toolkit has its own event queue, and each event queue is processed by a separate thread. Most SWT APIs must be called from the SWT event thread. Swing has similar restrictions though they are not as strictly enforced. This split is the major drawback of mixing the toolkits, and it adds some complexity to the code.

Applications must be aware of the current thread, and, where necessary, schedule tasks to run on the appropriate UI toolkit thread. To schedule work on the AWT event thread, use:

javax.swing.SwingUtilities.invokeLater()
javax.swing.SwingUtilities.invokeAndWait() 

To schedule work on the SWT event thread, use:

org.eclipse.swt.widgets.Display.asyncExec()
org.eclipse.swt.widgets.Display.syncExec() 

These are the same APIs used in a single-toolkit environment to keep the UI responsive while offloading long running operations to a worker thread. With Swing/SWT integration they are used for the additional purpose of moving work from one event thread to another.

The use of multiple event threads increases the risk of deadlock. Whenever possible, try to avoid blocking one event thread while scheduling work on the other event thread. In other words, avoid calling SwingUtilities.invokeAndWait from the SWT event thread and avoid calling Display.syncExec from the AWT event thread. Otherwise, if there's ever a case where one blocking call is made while the other thread has made its own blocking call in the other direction, deadlock will occur.

References

FAQ How do I embed AWT and Swing inside SWT