Software - Articles

Swing vs. SWT?

April 28, 2005

An article published in April 2005 by "Mr. Ed" entitled SWT Happens provided a list of reasons why SWT and JFace are an inferior solution for Java application development in comparison with AWT and Swing. Specifically, the technical quality and productivity of Eclipse as an application development platform was brought into question. However, having myself worked as a developer on several Swing-based and Eclipse-based products, the article missed the mark on several accounts and warrants a detailed rebuttal.

This article contrasts developer productivity when using the Eclipse and Swing platforms for application development, because this is a key consideration when choosing a technology stack. Unfortunately, the analysis of "Mr. Ed" is flawed precisely because he tries to frame the productivity debate in terms of AWT/Swing vs. SWT/JFace when, in reality, a more valid comparison is between AWT/Swing and the Eclipse development platform as a whole, which consists of many layers on top of JFace. When the features of the entire development platform are introduced into the comparison, it becomes clear why Eclipse is becoming the software development platform of choice for so many in the Java community.

The Plugin Model

First, consider the plugin model of development, on which the Eclipse platform is based. From a business point of view, plugins allow discrete pieces of application functionality to be packaged and deployed separately from one another. This has advantages from both business and technical points of view. From a business perspective, it simplifies the creation of separate but similar products (often referred to as a product line). For example, assume one is in charge of developing market analysis tools for stock markets, bond markets, and derivative markets. By developing the tools for each market in separate plugins, they can be easily combined to produce variations of a core product. For example, in addition to selling separate analysis tools for the stock, bond, and derivative markets, an "Enterprise-level" tool that combines all three tools can easily be produced. IBM has, notably, exploited this aspect of the plugin model to the point of vulgarity. It has been years since I lost track of the myriad editions of WebSphere Studio Application Developer.

A second advantage of plugin based development using Eclipse is that the problem of distributing updates is solved by the platform. By grouping together plugins into features and products for deployment, end-users can retrieve updates automatically using the update manager functionality built into the Eclipse platform.

Finally, plugin architectures provide several technical advantages as well. Perhaps the most important is that developers are compelled to plan out dependencies between parts of the code base earlier in the development lifecycle than normal. This is because code in one plugin cannot access code in another plugin unless it is explicitly configured to do so. Secondly, Eclipse plugins, through the use of export declarations in their manifests, also provide a formal mechanism to distinguish between public and published APIs (for more information on the difference between public and published APIs, see Public versus Published Interfaces by Martin Fowler.

At this point, it is instructive to draw a comparison with Swing and AWT development. If a project team chooses to develop an application using only Swing and AWT, they will not be starting with a plugin-based application development framework. If they want to take advantage of one, they will either have to adopt a framework like NetBeans or roll their own. Note: Having never developed a full-fledged application using the NetBeans platform, I am not sure how realistic this may be.

The Jobs API

Most business applications tend to perform long-running tasks -- generally when interacting with an external system of record. In addition to providing modal progress dialogs for such tasks, Eclipse also provides the Jobs API for executing multiple long-running tasks in the background while allowing the user to continue working. Furthermore, it provides an interface for tracking the current progress of jobs, and optionally, canceling them. Finally, the framework even has support for starting a task modally, and allowing the user to switch it to a background task! On the Job: The Eclipse Jobs API, provides an excellent introduction to this framework, and mentions many other features that this article neglects. Below is a screenshot of the Progress view provided by the platform to track execution of background tasks. A user looking at the view can determine that a single, cancelable task to create my online reservation is running, that the task is about thirty percent complete, and that it is currently trying to contact the reservation site.

Now, returning to Swing and AWT. How easy would it be to provide this level of control to an end user? The answer is "not very" and one would have to spend a significant amount of time reinventing features that Eclipse provides.

Decoration

A decorator refers to a piece of textual or graphical information that is used to augment the information conveyed by another entity. The use of decorators in applications is pervasive, and Eclipse provides a well-planned framework for both the development of decorators and their configuration by end users. See Understanding Decorators in Eclipse for an excellent introduction. Consider a few of the features that the Eclipse decorator framework provides:

  • Both text and image decorators are supported.
  • Decorators are implemented using the visitors -- a well-recognized design pattern.
  • Decorators are applied on a low-priority background thread.
  • End users can, optionally, be given the ability to toggle decorators on and off. Hence they have fine-grained control over how much information is presented to them.

Again, Swing offers no such framework to its users.

Analysis

The list of frameworks that are offered by the Eclipse development platform would take several books to enumerate throughly. However, in addition to decorators and job support, let me list a few that are extremely useful for application development.

  • JFace provides a wizard framework that makes defining wizards a snap. Swing provides no such framework.
  • Eclipse provides a framework for adding markers to any disk-based resource. Markers include a description and, optionally, locational information within the resource. Again, Swing provides no such framework.
  • The Eclipse platform provides a robust preferences framework. Sure we have java.util.prefs, but that only takes care of backend storage, not front display and modification of the values. With Swing, you would be left to code the front-end for user-configurable preferences yourself.
  • The Eclipse help system is fully integrated with the plugin architecture of the platform. Plugins can contribute help to specific topics within the help system.
  • A full featured status bar is standard issue with Eclipse-based applications. With Swing, you have to roll your own.

What should be clear at this point is that there is great asymmetry between Eclipse/SWT/JFace and AWT/Swing in terms of feature sets. Eclipse provides an application development platform whereas Swing provides a graphical toolkit with very few of the trappings needed for serious application development. It is inaccurate to claim, as "Mr. Ed" does, that:

"Due to the bugs and shortcomings in SWT, your developers will be working with a lowered productivity, and so you should expect project delays and/or increased resource requirements. Can your organization justify this extra investment?"

To the contrary, using Eclipse for application development is, I have found, far, far more productive than coding in pure Swing.

The Implications of Structure

I had a client that decided to write an application built on the Eclipse platform. By the time I arrived on the scene, several thousand lines of code from core JFace classes, such as TitleAreaDialog, had been copied and pasted into new classes. When I inquired as to the motivation behind such a move, it turned out that the developers wanted more fine-grained control over the details of the presentation. Specifically, in the case of the TitleAreaDialog class, they wanted control over the background color of the dialog window (which ought always to match the window settings of the user), and the height of the header area (which, for the sake of application consistency ought to be left alone).

It is, therefore necessary to understand the implications of providing the amount of structure that Eclipse does. It is easy to build using the Eclipse platform. Enormous amounts of functionality can be delivered in weeks. But take this bit of advice: don't program against the grain in Eclipse. Don't try to dismantle the framework and rebuild it to suit your tastes. So the height of the dialog header is 30 pixels instead of 35 -- or the cancel button for background tasks is red instead of mauve the boss wants -- or you want, as "Mr. Ed" did, an Outlook-like "cool-bar" instead of a "toolbar" -- or you want the font on the preferences dialog to be a size larger -- my advice is to forget about it. It most cases, these types of "requirements" are driven less by end-users and more by misguided members of development teams who think they know what is best for the user. Programming against the grain is so counterproductive in Eclipse and SWT that if your end-user requires extensive tweaking of the user interface, then I wholeheartedly recommend using Swing. It will certainly provide you the desired flexibility -- only, expect to pay a heavy price in terms of productivity.

Feedback

Comments are most welcome. Please send me feedback at my email account and I will post your comments here. Below is a small selection of comments I have received, that may further aid a reader's understanding of the concepts presented.

Marcelo writes on 12/28/2006:

Hi Amin,

I did not agree with your viewpoint in Swing vs. SWT article.

I know that Eclipse framework is a great solution: JFace, dragglable windows and so, but these technologies are built-in over SWT API.

The core SWT is weak. In my concept, SWT uses many shortcuts that make easy the development of small applications but implies limitations in complex enviroments (example, a non fully implemented MVC model). In this context, the Eclipse framework is a solution.

For your article, I propose the title "Swing vs. Eclipse Framework" and, in this case, the comparsion sounds like "Davi vs. Golias".

I like Swing and know that it claim a high level APIs, but Mr. Ed stay correct in the original text.

Finally, points for IBM/SWT/Eclipse community.

Sincerely. Marcelo

Amin responds:

Hi Marcelo,

Thank you for your thoughtful comments.

If you notice, the title of my article is "Swing vs. SWT?". The question mark at the end denotes a question, in this case "Is such a comparison valid?", and, as I try to explain in the article, it is not a valid comparison: if you are a project manager trying to figure out which toolkit to use for your product, the choice is really between Swing on the one hand and the Eclipse framework on the other. Therefore, your point, that the choice of "Swing vs. SWT" really is more a question of "Swing vs Eclipse Framework" is one I agree with completely, and, indeed, if you consider all the features the eclipse framework provides out of the box, it is a hands down win over Swing for most applications. I have yet to see such a cohesive, widely used application development framework in the Swing community.

The reason for the title was because this small article was a response to Mr. Ed's original article in which he tried to compare Swing and SWT, concluded Swing is a more flexible framework (which I agree), and then erroneously concluded that developer productivity will be better with Swing.

I hope that this clarifies my position.

best, Amin

Benad writes on 9/18/2005: 

> But take this bit of advice: don't program against the grain in
> Eclipse. Don't try
> to dismantle the framework and rebuild it to suit your tastes. So
> the height of the
> dialog header is 30 pixels instead of 35 -- or the cancel button
> for background
> tasks is red instead of mauve the boss wants -- or you want, as
> "Mr. Ed" did, an
> Outlook-like "cool-bar" instead of a "toolbar" -- or you want the
> font on the
> preferences dialog to be a size larger -- my advice is to forget
> about it.

So... You're locked in to whatever is their default implementation of their GUI widgets.

I make GUIs as part of my work and you can't imagine how often the clients come back with a huge list of GUI tweaks which, come to think about it, increases their productivity, hence have to be done.

Oh, and their Mac OS X and Linux port are *horrible*. Worst than the JRE 1.4 "metal" theme of Swing. Whoever is working on Eclipe and SWT *really* dropped the ball on cross-platform GUI development.

Using the gui4j library (http://www.gui4j.org/) I'm building the GUI *and* the controller code in minutes, so I'm confused about what are the gains of performance you describe in your document. There are other such libraries out there, and I heard NetBeans' 5 GUI builder is quite good, but I haven't tried that.

Not only that, but Mr .Ed (adn you) compare apple with oranges, i.e. the SWT *platform* with the Swing *component library*. You should compare the SWT platform with the NetBeans platform (built on Swing) for a fairer comparison.

As you can see, I tend to avoid tools that "lock me in", and I think this is an attitude that should be essential for all software engineers. That's why, from time to time, I do my Java development in jEdit and Emacs. All tools have their strength and weaknesses, but I still want to have a choice in the end. And this makes me more productive than any specific choice I can make.

- Benad

Amin responds:

Hello Benad,

thank you for your email. I want to address some of the points that you make because, to an extent, I am in agreement with what you say, and I think I could have done more to clarify the context of my discussion in "Swing vs SWT?".

First, I will readily concede that it is not valid to compare Eclipse, a development platform, with Swing, a GUI toolkit. However, when Mr. Ed slammed SWT in his article I felt that the focus of his commentary was itself misplaced. Within the context of business application development, it is much more important to consider the merits and demerits of Eclipse as a platform, not of SWT in isolation. This was the point that I was trying to make in my article.

Now, as you have mentioned, Netbeans is a platform similar to Eclipse that has been written using Swing, and what would really be useful is to compare the capabilities of these two in supporting business application development. I concede this point, and I even made a brief reference to this fact in my article.

In order to adress some of the other points you make, I want to provide you with a little bit of my own background. I also work on GUI development, mainly for financial institutions here in US. In my own experience, most of the companies are completely locked into Windows and the rich-client applications that they need written for them need only to run properly on windows. Therefore, when you mention that the OS X and Linux implementations of SWT are poor, I concede that I am not qualified to comment, but I have heard similar remarks made by others, too. The Windows-only assumption also makes it possible for me to integrate Swing widgets directly into my Eclipse-based application when necessary, since Eclipse, post 3.0 on Windows platforms supports direct embedding of a JFrames. Practically speaking, however, I have nevery utilized this functionality for any products that I have delivered.

You mentioned that your own clients generally come back asking for productivity enhancing tweaks to the user interface. I agree with you whole-heartedly that the productivity of the end user must be maximised and should never be sacrified. However, I have not, in my own experiences, come across a situation where enhancing the end user's productivity required custom-coded widgets or tweaks to button-height, font characteristics, and the like. Perhaps you can provide me with one or two concrete examples from your own experience?

Finally, you mentioned the gui4j library, and I did take a look at it. It looks to me like it improves productivity as far as constructing screens is concerned, and based on your comments, it seems like it also simplifies the controller tier of the application. However, these are only two parts of developing an entire application, and the Eclipse development platform goes far beyond this in terms of supporting application development. In addition to the infrastructure provided by the base platform that I highlighted in my article (e.g. error markers, asynchronous job framework, user preferences framework, etc.), have you looked at tools like EMF (http://www.eclipse.org/emf/) and GEF (http://www.eclipse.org/gef/) ? EMF is an MDA (model driven architecture) tool that not only generates high-quality java models from UML diagrams or W3C XML Schemas, but also 1) generates an edit layer on top of the model that can be used to make modifications to a model instance using the "command" design pattern 2) generates adapters for the model objects that allow them to be graphically displayed to end users, and even 3) generates a fully cusomizable, Eclipse-based editor for the model instances that supports undo/redo, drag and drop, copy and paste, etc. And EMF also supports model serialization to and from XML, out-of-the-box.

I won't get into GEF, as the email is getting too long, but I've included the link in case you are interested. In my own experience, I have not found a Java-based application development stack that is as comprehensive and well-integrated as Eclipse.

Finally, in closing, I wanted to also mention that I am also a big fan of jEdit, and I use it on a regular basis.

thank you for writing, Amin