Desktop Java with SWT: an interview with Steve Northover

I’ve been fortunate enough recently to be in contact with Steve Northover. Despite him being very busy with SWT and the forthcoming release of Eclipse, I’ve managed to grab some of his time to answer some of my questions. To clarify from the outset, the views expressed by Steve are his own and not those of his employer.

Steve, thanks for taking time out to answer some questions. Could we get things started by you giving us some background on yourself with respect to becoming a Java developer?

Hello everyone, I’m Steve Northover, the principal architect of SWT. I’m what is sometimes called a Technical Manager which means I write real code and fix bugs as well as do planning and other less fun activities.

I started out at Object Technology International (OTI) as a Smalltalk programmer, way back in 1990. We built products using the most suitable technology for the job because shipping products, and not technology, is what keeps a small company alive.

When OTI moved to Java, I moved with it.

I’m assuming that SWT development takes up most of your time, however, are you involved in any other projects at the moment?

I’m always pretty busy around Eclipse.org but SWT is my primary focus. I’m afraid that I’m a widget addict. I never met a window system I didn’t like. There is nothing else I would rather be working on. For me, widgets have always been fun and interesting.

SWT

You are quoted as saying “If you stop to think about it, we support 5 different operating systems using totally different code bases and somehow knit together and implement a portable API to all of them and we do this for free. It’s a full time job, 24-7.” Bearing this in mind, why did IBM feel the need to develop SWT at all? Is it worth it?

The most interesting thing for us at OTI was always building and shipping products. This remains the focus today, now that we are part of IBM. I’m not going to repeat the whole history of SWT here because it’s available from multiple sources. What I will say is that when we went to use Java to build the successor to VisualAge for Java, we decided, based on our previous experience, that developing SWT was the best way to solve the problem. Honestly, I think it has worked out rather well.

Native widgets aside, the SWT architecture is considerably different from Swing’s. What were the factors that influenced the eventual design?

There were many. I learned a lot of things from the Smalltalk world and the experience I had programming there. One thing I found was that the power of OO languages led people to over-engineer their solutions. Discovering this was not rocket science, but I had to make those mistakes once myself to see it. However, I learned and swore that I would never do it again. That’s where some of the SWT “less is more” philosophy comes from. Occam knew what he was talking about.

I also discovered that in the end, people don’t usually care how your software is implemented, they just want it to work and be as small and fast as possible. Hence, the focus on efficiency. By the way, that’s absolutely not a negative statement about anyone else’s technology.

When we started SWT, I promised myself I was not going to build a gigantic, unmanageable, programming mess. Native widget toolkits are always on the edge of being just that. It’s not that any particular aspect of it is really that complicated, but the amount of detail can become overwhelming. There’s also the problem of language mismatch. Native widgets are traditionally programmed in C, not Java. Our approach, mapping the platform APIs as directly as possible to Java, has turned out to be a successful way to deal with this.

SWT’s native look and feel has certainly enamored many Java developers. What other aspects do you feel SWT excels at?

The design of the toolkit is clean. It is designed to provide the thinnest possible interface between you and the platform and provide tight native integration. It starts fast and has a good memory footprint. The community involvement with its ongoing development is also a strength.

One of the problems SWT faced was that in order to create a portable API using native widgets, you must always restrict functionality to the lowest common-denominator. Has this been frustrating? Do you think an optimized, emulated toolkit would have been better in hindsight?

No (to both questions). With native widget toolkits, the thing that is important is to focus on what is absolutely necessary to build portable applications. Sometimes trade offs are required and we decide not to expose rarely used platform functionality. In other cases, platform constraints influence the design. For example, in SWT, you need to provide the parent when constructing a widget. Believe it or not, this was controversial. On Windows and some other platforms, a widget can’t be created in the operating system without one. This single design decision cut out all the problems associated with copies of widget state, some in the operating system and some in Java. Native toolkits are hard to design and build but provide a number of unique advantages over an emulated approach.

Some recent articles have criticized SWT development as being prioritized towards the needs of the Eclipse project. Is this a fair assessment?

Eclipse is certainly a major client of SWT and influenced the early development of the toolkit. However, there are many factors that determine what we work on. The SWT committers work hard to help anyone doing real things with SWT.

Are you surprised by the amount of controversy SWT has caused?

The native versus emulated debate has been going on for at least 15 years. Before Java, we built a portable native widget set for Smalltalk. Sometimes history repeats itself.

Many people want to build applications that are indistinguishable from native ones. For better or for worse, they want to use native technologies like Windows GDI, Macintosh controls, or GTK widgets and Pango text rendering. This really does make some amount of sense. It builds on the work of the native toolkit implementers and operating system vendors. There are excellent programmers hard at work at places like Microsoft, Apple and in the open source community. We should take advantage of this work in our Java applications.

What is JFace and how does that fit in with SWT?

JFace is a model and utility layer that is built on top of SWT. It’s another component of the RCP (Rich Client Platform) and Eclipse, just like SWT. It’s an interesting idea to have the model layer architecturally separate from the widgets. It means that people who like models can work with them and those that just want the widgets can program them directly. This kind of separation is both powerful and flexible.

Do you think SWT has allowed Java to graduate as a serious contender for development of professional desktop applications, or was it already there?

I would never pretend that SWT is responsible for the revival of interest in Java on the desktop. However, the fact that SWT embraces the operating systems makes it attractive to people who believe that native widgets are essential. Windows programmers who were considering C, C++, MFC, ATL or even C# for their next project are looking at Java and SWT. Open source programmers also like the fact that when they use SWT, they are really leveraging technologies like GTK and their work can be compiled easily to native code using GCJ.

What does the future hold for SWT? What new features can we look forward to?

Of course, we plan to just keep making it better. In terms of features, we are working on the list right now. The best way to track this is to check the next revision of the Eclipse platform plan at Eclipse.org. Also, like everyone else in the industry we are interested in new technologies like Longhorn.

Open Source

SWT is released under the OSI approved EPL license, which allows users to obtain, modify and redistribute the source code. Has this model helped SWT to progress at a quicker rate? Does the multi-platform support prove a barrier to many interested contributors who only have a subset of the target platforms?

Way back in 2001 when Eclipse became open source, many people asked me if I was afraid to let people see the code. No way! I’m pleased with what we’ve achieved and when someone contributes a patch or finds a bug, I’m proud rather than protective. I’m constantly amazed at the number of people that are poring through the source code and helping to make SWT better. None of this would have happened if we didn’t release SWT under open source.

To really implement a feature well, you need deep multi-platform knowledge. However, the fact that SWT is so close to the platform allows contributors to leverage their operating system skills. It’s easy to find where things are done in SWT because the code is straightforward.

Sun has finally succumbed to pressure to open source their Solaris operating system. With Solaris being such a key asset to Sun, do you think they will follow through and open source Java? Do you think Java should be open sourced?

As a developer who has worked on both closed and open source projects all I can tell you is that open source is way more fun. For example, when you fix a bug, you really make someone happy. The feedback is instantaneous. There’s also a great feeling about working in the open. However, these are just my opinions. Personally, I like open source but I don’t presume to tell other people what to do or speculate on corporate strategy.

Java Desktop

I’ve heard people suggest that Java only has a role in the enterprise environment within back-end, middle-ware and web-services domains. The idea that Java can compete with native platforms for professional desktop applications doesn’t parse with many non-Java developers. Is this a fair view? What needs to change to improve Java’s reputation on the desktop?

There are plenty of examples of competitive desktop application built using Java. In my experience, most of the concerns surrounding the use of Java on the desktop have been related to either performance or native integration. Performance isn’t an issue, providing that programmers don’t make the mistake of making things too complicated, which is a danger in any language. Our focus has been on native integration.

Which projects (if any) out there best illustrate to you that Java is a solid platform for the desktop?

Obviously, Eclipse. As far as SWT is concerned, Azureus (a BitTorrent client) and RSSOwl (a newsreader) are two popular applications. Last time I looked, Azureus was the top download on SourceForge. If you check the Swing Sightings, you’ll see numerous programs built with Swing such as Limewire, Yahoo Sitebuilder and Encyclopedia Brittanica (CD-Rom edition). All of these applications show that Java is industrial strength on the desktop.

Anything else I’ve missed that you would like to share?

Java should be about inclusion. Libraries such as SWT and Swing bring widget programming to Java and showcase exactly how powerful the language is. The tools are there to do the job.

Many thanks for your time 🙂

About the author:
Andrew Roberts is a computer science graduate from the University of Leeds, UK. He remained at Leeds to study further towards a PhD in Natural Language Processing. He has been using Linux for almost 8 years, and Java has been his language of choice for advanced language processing and machine learning during the last three years.

21 Comments

  1. 2005-06-16 8:42 pm
  2. 2005-06-16 9:32 pm
  3. 2005-06-16 10:32 pm
  4. 2005-06-16 10:56 pm
  5. 2005-06-16 11:11 pm
  6. 2005-06-16 11:27 pm
  7. 2005-06-16 11:31 pm
  8. 2005-06-16 11:32 pm
  9. 2005-06-17 12:53 am
  10. 2005-06-17 1:00 am
  11. 2005-06-17 3:23 am
  12. 2005-06-17 5:59 am
  13. 2005-06-17 6:37 am
  14. 2005-06-17 10:30 am
  15. 2005-06-17 12:22 pm
  16. 2005-06-17 1:22 pm
  17. 2005-06-17 1:41 pm
  18. 2005-06-17 2:42 pm
  19. 2005-06-17 6:09 pm
  20. 2005-06-18 9:36 pm
  21. 2005-06-23 3:56 pm