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.
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:
Again, Swing offers no such framework to its users.
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.
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.
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.