Alex headshot

AlBlue’s Blog

Macs, Modularity and More

EclipseCon Swing, SWT and VE

2006, conference, eclipse, eclipsecon, swt

There were a few interesting talks today concerning the two sparring partners, SWT and Swing. The first was a set of experiences when migrating a Swing application to Eclipse. What was interesting about this was the level of detail that the talk went into about some of the problems, issues and solutions that might face others in the future. Of course, there are still known issues with SWT_AWT on Mac, but progress has been made recently (though nothing will be available in the 3.2 timeframe), which means that companies wanting to reuse existing UIs can't rely on that platform for the time being. Although it can be used to nest Swing UIs in an Eclipse frame, certain UI behaviours (like stealing tab focus and not being able to fit in with the UI) can cause issues from a coherent user interface point of view. Continuing to work on a single UI is probably the best solution, regardless of choice of UI.

Getting into details, the talk outlined some of the issues with SWT and Swing with regards to threading. SWT components vociferously check whether the caller is in the UI thread before allowing modifications, unlike Swing which just passively ignores (which potentially causes problems) in such situations. Thus a Swing app migrated to SWT may have deadlocks which aren't visible in the Swing version. (Of course, the Swing version may have had unintended behaviour before that was an unknown error; the SWT allows the caller to verify the existence of such problematic code earlier.) Other low-level issues, such as the use of Fonts and caches in SWT instead of the Swing counterparts, could result in different memory usage scenarios. The SWT versions tend not to use as much Java heap space as the Swing versions do, because the SWT are just lightweight wrappers around the native implementation.

The two big things that bite new developers to SWT is that they must explicitly manage resources with dispose() calls. This can result in memory leaks of native resources/handles if not appropriately handled. The second is that construction of SWT widgets must always be in parent/child order, since the children must be passed a handle to their parent at creation time. Though unlikely to be much of a concern, it can require some reordering of code that a Swing implementation has.

Taking a step back; the bigger picture is that there are services and utilities that aren't available in Swing. Although both Swing and RCP have help, the RCP help is much richer in terms of facilities. Also, RCP can manage preferences via the preference store and present information via the preference pages. Bringing a Java/Swing app across is more than just the UI; it's about learning how to leverage the benefits of RCP. As a result, if there are any self-implemented preference pages, then there is an opporunity for refactoring to use the new interfaces. Although this may result in the disposal of old code, the benefits gained make it a more convincing argument than leaving an older implementation in and having to migrate specific UIs. If that isn't suitable, then the underlying storage can still be adapted to provide an IPreferenceStore and the UIs for preferences can still be leveraged.

Dealing with tabular and tree data is also done slightly differently in RCP than it is in Swing. There are a richer set of operations that can be done on a table; it can be filtered or sorted based on externally supplied routines; and there is a workbench-wide selection service that can be leveraged to maintain a consistent set of operations throughout the UI. It's also possible for others to contribute per-item actions based on the type of item selected. These may have an impact on the design of the system as it stands; a greater or lesser amount of work may be needed to take advantage of these new features.

In some cases, the UI may have to be redesigned. RCP's views work very well for presenting information in small identifiable chunks. In an Outlook mail client, there will be a preview pane, an inbox pane, and maybe a calendar pane. These could all be presented as independent views in an RCP app, or it could be merged using a complex set of GridLayouts in a Swing application. However, the work involved in compartmentalising the UI has benefits; the end user can now decide how to arrange the layout in more ways than 'split horizontally' and 'split vertically'. The good news is that this work can actually be very beneficial, even staying in a Swing environment; componentising the UI is good for maintenance.

The upshot is that there are some low-level differences between SWT and Swing that are easy enough to work around when you migrate between the two. However, leveraging what RCP is good at may require more substantial work, which is where considered use of the SWT_AWT bridge may be useful. However, a full migration towards RCP will result in greater savings in the future in terms of maintenance and reuse as well as user satisfaction.

There was also a presentation on three visual editors; Eclipse's VE, Cloud Garden's Jigloo, and Instantiation's Window Builder Pro. Of course, VE's basis at is known, but it can edit not only SWT but also AWT/Swing as well. A few screenshots showing VE's capabilities were presented, with the only obvious point being that VE only works on the latest build(s) of Eclipse. The other competitors -- Jigloo and WindowBuilderPro -- work on older versions of Eclipse, primarily to serve their customer bases using WSAD on versions as old as Eclipse 2.1. To be honest, the presentation was an overview of most of the basic features, and I didn't come away knowing much about the advantages/disadvantages of one or the other. That's not to say there aren't any; but the presentation was being presented by someone who was commercially related to WindowsBuilderPro so perhaps it's better that there wasn't an analysis like that in the presentation itself. All seemed reasonably capable; possibly, the style of code generation is different between them. Some people never liked Visual Age's way of creating a new accessor method for each widget (though it did allow Visual Age to create information on demand), and I seem to recall hearing a few comments such as 'This visual tool uses Visual-Age style widget creation accessors, whereas this one doesn't' but I don't have accurate information as to which that applied to.

In any case, the presentation seemed to imply that the marketplace was large enough to have two commercial and one open visual editor, so competition will improve the situation for everyone. Of course, others exist (Matisse in NetBeans, as well as the Matisse4MyEclipse; and others such as RAD provide value-adds that may share some common set with VEP). Matisse, whilst being easy to use, has the disadvantage that it 'locks' the code against editing. Other tools may do this; but from what I can gather, code such as WindowsBuilderPro and VE work by executing the code rather than enforcing its structure, which means that they can display/manipulate more arbitrary code. Of course, you'll want to investigate the quality of code generated out of any such tool, and what restrictions are placed on editing that code after it's been generated (and if so, whether that code can be opened in the visual editor afterwards). A good point to investigate with any visual editor is whether it can be used to build up components; so instead of dumping everything into one layout manager, if individual component widgets can be created, and then assembled into larger interfaces.

Hopefully that's vaguely useful and at least gives a few links to visual editors for Eclipse if you need such facilities.