Swing and SWT: A Tale of Two Java GUI Libraries

• facebook
• twitter
• google+
• in
• Email

SWT vs. Swing

We conclude this article comparing these two technologies. Which is better, and when?

Swing provides a larger set of features, it is much more elegant, and gives an higher abstraction level (that turns helpful when developing complex GUIs with custom components). In general, SWT is easier to use at first, but when it comes to building complex GUIs, Swing usually results are easier to use and more flexible. In Table 1, support for the main components is shown for the three main GUI libraries.

Table 1: Comparing visual components
Component	SWT	Swing	AWT
Button	X	X	X
Advanced Button	X	X
Label	X	X	X
List	X	X	X
Progress Bar	X	X
Sash	X	X
Scale	X	X
Slider	X	X
Text Area	X	X	X
Advanced Text Area	X	X
Tree	X	X
Menu	X	X
Tab Folder	X	X
Toolbar	X	X	X
Spinner	X	X
Spinner	X	X
Table	X	X	X
Advanced Table	X	X

At first, SWT may seem simpler to use than Swing because it spares developers from a lot of sophisticated issues (such as the elaborated Swing class hierarchy, pluggable look and feel, the Model-View-Controller approach, and so on). Anyway, one potential problem with SWT is in the need for resource management. Swing (and AWT) follows the Java paradigm of automatic resources disposal, while in SWT de-allocating native resources needs to be accomplished explicitly by the programmer. Explicitly de-allocating the resources could be a step back in development time (and costs) at least for the average Java developer. This is a mixed blessing. It means more control (and more complexity) for the SWT developer instead of more automation (and slowness) when using Swing.

Although SWT supports non-natively rendered widgets (similarly to Swing), the default widget implementations are based on native peers (similarly to the old AWT). In addition, most of the Eclipse peers do not allow for inheritance. (Obviously, if you're writing Eclipse plugins, you have no choice but to use SWT.)

Recapping, whenever one needs a tight integration with the native platform, SWT can be a plus. Similarly, if one wants to take advantage of the Java language but needs to deploy only on Windows (or some of the few other supported platforms), SWT (and the Eclipse platform) is a better choice than Swing. But, be careful about the hidden costs associated with learning to use the Eclipse IDE and the SWT library. Also, the explicit de-allocation mechanism adopted in SWT could be useful in some situations and uselessly complex in others. If you don't need cross-platform development and your target OS is supported (Windows, for example), you may consider SWT, especially if your customers have old, limited machines where Swing use can be prohibitive. For all other scenarios, Swing provides the conservative choice.

Conclusions and References

In this article, we introduced SWT and compared it with Swing. My intent was to give a first idea of this library and its main characteristics. We concluded contrasting briefly SWT against Swing.

In the following are listed some (among the many) resources available for the interested reader.

• http://www.eclipse.org/—The home page of the Eclipse project.
• http://gcc.gnu.org/java/—The home page of the GCJ project.
• http://www.java.sun.com/products/plugin/—The official Sun Web site about Swing technology.
• http://www-106.ibm.com/developerworks/library/j-nativegui/—The site for Vogen, Kirk's article "Create native, cross-platform GUI applications."

About the Author

Mauro Marinilli is currently finishing his second book, on professional Java graphical user interfaces. He teaches CS courses at the University of Rome 3 in Italy while being active as a consultant and as an academic researcher in case-based reasoning, Human Computer Interaction and its applications to e-learning. You can email him at contact@marinilli.com.



Page 2 of 2