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.
SWTYou 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.
- "Interview, Page 1/2"
- "Interview, Page 2/2"