SWT running on Swing: Christopher Deckers on the SWTSwing Project

As soon as the Standard Widget Toolkit (SWT) Java UI API was released, developers as wondered if a Swing implementation could be written. A number of efforts have come and gone but the new SWTSwing project is quicking making this desire a reality. The most recent release supports the majority of SWT widgets such as Button, Canvas, Label, Text, etc. Partial support is available for Tables and Trees. The current version is able to run the popular bit torrent client Azureus and is being used as the foundation for the Eclipse on Swing project. InfoQ sat down with project lead Christopher Deckers to discuss the project.

The first question developers ask when they hear about this project is "Why?":

I never opposed Swing to SWT as they are each good at different things. I thought it would be good that one of these UI toolkits uses the other in order to have the best of both worlds. When I started, the initial benefit I saw was portability: getting rid of the dependency upon native libraries and having a consistent behaviour accross platforms is really important in some contexts. Additionaly, it allows advanced UI customization to the SWT components through the use of look and feels and the possibility to tweak the underlying Swing components. There are of course many more advantages, like having SWT available on more platforms, integration of third-party Swing components, etc.

In regards to SWTSwing's current compatibility level Deckers replied:

Most of the widgets are completed, and all the basic UI objects (Font, Color, etc.) are all working as expected. The more complex components, mainly the Table and the Tree widets, still require a bit more work but can already handle most of the normal use cases. Advance features such as BiDi, accessibility or Drag and Drop currently have a limited support.

There is of course the problem of implementing portions of the API SWT that currently do not have equivalents in the Java runtime. I have in mind the Browser widget (Swing's JEditorPane does not qualify as a web browser), mouse cursor handling or window transparency. Some other features (System tray, extended modality support) will be implemented when Java 6 is officialy released.

Anyone that has ever used both Swing and SWT knows that they are very different API's despite both being written in Java. We asked Deckers about what had been the most difficult areas in bridging the two API's:

The event pumping is by far the most complicated and tricky issue of all. There is a fundamental conceptual difference between Swing and SWT as to how events should be pumped: Swing has its own thread managed for you, but SWT wants to control that thread... It took a long time, several rewrites and iterations to come up with a solid design to solve this puzzle. An other problem was that when I started, many features could not be implemented with the Java runtime of that time.

Our conversation then moved on to speed:

It is hard to tell, for various reasons. First, Swing's speed slightly varies between platforms and SWT's speed varies a lot. Moreover, I am still at an implementation stage and there probably are some areas that can be optimized. Overall, I would say I am pretty satisfied of the speed I obtain when I test applications like Azureus or RSSOwl.

As far as where the SWTSwing project will go in the future, Deckers stated that SWTSwing is just a brick that can be used by SWT applications. It is just as applicable to Eclipse RCP applications as the Eclipse IDE itself:

Some hate the idea, some clearly already have a need for it, and the political impacts of bringing Eclipse and Sun technologies closer together are interesting. I believe that all the SWT applications, the eclipse platform and the Java community in general can gain a lot from this portability layer and extensions, which eventually contributes to making "Java on the desktop" a reality.