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.
I wish “Java Faces” or whatever “the higher framework” above SWT is was a bit more “fleshed” out.. it’s still no swing API. You have to give Sun credit for a very well designed GUI API. It really is top-notch even if it doesn’t look great:)
But even with the Mustang b39 “the subpixel build” not as good as cleartype. but i’m a sticler for fonts”). the trick on linux is “medium-hint”. rayiner knows about this stuff. freetype is no cleartype, but still looks better than swing post-b39.
I’ll give them a big break for finally getting it into swing. How many years have we all been using LCDs now? really.
The Mustang b39 with the Java Faces and the SWT mixed with beans is a way cool Desktop.
“When we started SWT, I promised myself I was not going to build a gigantic, unmanageable, programming mess.”
The road to bloatware is paved with…
Try having a beginner use SWT/JFaces/Eclipse/etc to actually write an application and you will be stunned as to how impossible it is.
While SWT certainly is miles beyond AWT, it is still mired in bad design that did not scale up beyond simple widgets at all well — and also stymied by Java’s horrible architecture and myopia when it comes to interfacing with native platforms.
After all these years, Sun Java still does not have transparent COM support, transparent Win32 support, transparent .NET support, etc. This lack of native platform support makes writing “nice” Java client applications … something which will never happen.
No one can argue with the popularity of Eclipse. It is the only free IDE that has a lot of features. But it is steadily collapsing under its own weight. Which makes it suited only for corporate IT worker units who are trolling away on some giant outsourced project where personal productivity and elegance does not matter.
IBM is going to wake up in a few years and wonder what happened. Building a giant Titanic of a Java IDE is going to turn out badly. It may be big iron, but it is not strong iron.
I think it’s a hit, and you’re misinformed…
Try having a beginner use SWT/JFaces/Eclipse/etc to actually write an application and you will be stunned as to how impossible it is.
That’s like asking a beginner to write a fully enabled EJB based application with web apps, xml services, and rcp clients. … or the equivalent in .NET. Have a beginner start with basic SWT, and they’ll soon find out it’s not hard at all. Then add JFace. Then add the Eclipse plugin architecture.
The neat thing about SWT is that it’s really very small, easy and straightforward by itself. And, if you are complaining that it doesn’t give you any funtionality by itself, I’ve written several *large* applications in straight SWT and they’re fully functional. Plus, if you’re going to write SWT apps (or any GUI apps for that matter) get a good GUI builder. Eclipse VEP, Jigloo, or SWT-Designer.
While SWT certainly is miles beyond AWT, it is still mired in bad design that did not scale up beyond simple widgets at all well — and also stymied by Java’s horrible architecture and myopia when it comes to interfacing with native platforms.
The SWT forms that I’ve created scale quite well – plus how much scaling are you talking about? You’ll reach the ‘usable’ desktop limits before you hit any type of technical scalability limits. Also, the whole point of Java is to be cross-platform – hence the reason it *doesn’t* interface with native platforms directly.
After all these years, Sun Java still does not have transparent COM support, transparent Win32 support, transparent .NET support, etc. This lack of native platform support makes writing “nice” Java client applications … something which will never happen.
Again, please explain. All this support you talk about is available using freely available bindings, libraries and such. Maybe it doesn’t come in Java itself – but why would it? These aren’t cross-platform APIs/protocols/etc.
Which makes it suited only for corporate IT worker units who are trolling away on some giant outsourced project where personal productivity and elegance does not matter.
The reason our business is using SWT is precisely because productivity matters. Using a great IDE like Eclipse, and coupling it with a great GUI builder you would be amazed at how much you can get done. …and as far as elegance goes, you’re talking to the wrong people (Java devs) … if you want to see inelegant code go talk to the VB6 guys.
IBM is going to wake up in a few years and wonder what happened. Building a giant Titanic of a Java IDE is going to turn out badly.
IBM did wake up – they realized they needed something to compete directly with .NET and Visual Studio – and Swing didn’t cut it. But, SWT does and the stuff that the Eclipse team is doing with their RCP tools is really unbelievable.
It may be big iron, but it is not strong iron.
Um … this is software we’re talking about – no iron involved.
SWT on its own is mostly okay. The widgets are not the best, but they do work. And they are better than anything that can be done via “pure” Java.
I think it is hypocritical to say SWT is good (and it is largely native code) but other native code would be bad. If Java had native COM, native Win32, native .NET on Windows, writing stuff far better than SWT would be simple and enjoyable. Maybe I want to use Java/Eclipse/SWT and I don’t care about running on Linux? Why should I be locked out of making a good app?
Scaling up — in terms of application size and complexity — from SWT, the application model breaks down rapidly. The payoff vs. complexity curve is not pretty. Essentially all the madness of EJB has been ported to the desktop.
I believe this is mostly due to IBM’s influence although Eclipse came from a UK shop and the Brits always produce massive frameworks that are overengineered on the outside and underengineered on the inside.
IBM due to their size and is getting traction with Eclipse. However, the current Sun version of Java is for servers. It is not a good foundation for any kind of client application. I think this point is lost on IBM and many of the Java jockers who are still drinking the dotcom Java koolaid.
Thus looking at Eclipse and client applications, it is a big ship headed out to sea, headed for oblivion. These big ships are good for IBM server space and the big iron world, but not appropriate for modern client apps.
When the day comes that I find an Eclipse RCP application that is useful, simple to installl, and easy to use, then maybe I will take another look. For today, there are better options for most developers who are not contractually or economically tied to IBM/Java.
At least I can burn a binary on windows and linux an not fuss with a damn runtime besides what GCJ gives me
Plus, the fonts still look like crap in Java 5
Hello, anybody listening!
Haha! Well said, bruda! I feel exactly the same way about Java/.NET. I call them corporate Koolaid.
I was trying to compile the swt.jar (from eclipse 3.1) with gcj 4.0.1pre, no way for me, any suggestions?
All non-gui apps seem to compile fine though…
I’ve personally received support from Steve at eclipse.platform.swt and I’d like to say thanks again. He puts his blood, sweat and tears into swt! swt is great, and it’s my gui toolkit of choice and I’ve used many over the past decade. I get great windows xp desktop performance with my application and all the benefits of development in java.
I don’t get why someone always has to complain about fonts in Swing apps. They look just like fonts everywhere else. I’m using jEdit on Debian Sarge with … ok, I hate to admit it, but I’m using Sun’s 1.4.2 (dunno if jEdit works with GCJ4 — I need to try it though). The text area of the editor has antialiased font rendering (though you can turn that on or off), and the menus just use some small X11 bitmapped font. It’s lovely.
The *first* thing I did long ago when configuring my desktop was shut off subpixel font rendering. It leaves very distracting color artifacts. Pure black-n-white pixels look much better to my eye — especially on my beautiful LCD monitor.
Anyhow, jEdit is written in Swing and the fonts look perfect. Exactly like fonts in, say, Firefox.
especially for IDE’s, anti aliased fonts suck big time. and i agree,i dont have a big issue about java and fonts. Anyway, for people to bash Java, after this issue is fixed (which is fixed in Mustang already), they will have another slogan..
But one thing you said made me confused, why do you feel bad using Sun’s java? it is not piracy. it is posibly the best java implementation out there. (JRockit is also good tough.). it free, and always be free.
it is not mandatory to accept GPL as a computing religion when you use Debian i assume
.
“I don’t get why someone always has to complain about fonts in Swing apps. They look just like fonts everywhere else. I’m using jEdit on Debian Sarge with … ok, I hate to admit it, but I’m using Sun’s 1.4.2… Anyhow, jEdit is written in Swing and the fonts look perfect. Exactly like fonts in, say, Firefox.
OK “
John fire up Jedit and reset the look and feel to GTK+ then look at the system fonts on the menus then compare to Firefox. The Java fonts suck compared to the Native fonts on Firefox. Now fire up an SWT application like Eclipse, Azureus or RSSOwl and look at the system fonts there and the look the same as on Firefox.
SWT gives genuine native GTK2 GUI for Linux apps where Swing sucks and the widgets don’t work quite right either. Set your screen resolution to 600×800 and fire up Limewire with the Limewire look and feel – now set the look and feel to GTK+ and the widgets are all out of place and virtually unusable.
However Swing apps using the Windows look and feel on Windows XP do appear pretty much native and the fonts are fine. If you want your app to look native on Linux then SWT is the way to go.
One thing I don’t like is that the SWT license (EPL) isn’t compatible with the GPL. That means you are not allowed to use GPL code with SWT. Afaik the patent clause in the EPL is the reason for the incompatibility… Hopefully with GPL v3 the EPL will be considered compatible…
fs
I always hated java’s layout managers. An overdesigned solution to a small problem. I mean, how often do you resize windows? I almost never do. I could never get my dialogs to look how I wanted them to look.
A shame SWT is not better than AWT/Swing in that regard.
I love how .net solves that problem with no effort using anchors.
Yeah im not even close to being objective. I love .net and hate java. When I write a program in C# it very often works the first time I compile it, where as in java I always have to spend hours looking at some trivial peace of code because there is always something in the java class library thats implemented in some incredibly wierd way. Like counting months from 0, or not displaying the header in JTable because I used the gridbagconstraints layout manager.
And I like working in an IDE that doesnt eat up my entire RAM and doesnt eat up 100% of my CPU for no apparent reason way to often.
I always hated java’s layout managers. An overdesigned solution to a small problem. I mean, how often do you resize windows? I almost never do. I could never get my dialogs to look how I wanted them to look.
A shame SWT is not better than AWT/Swing in that regard.
I love how .net solves that problem with no effort using anchors.
SWT comes with a FormLayout that basically does this. You anchor the widgets just like in .NET, VB … couple this with a good GUI builder and your set. As for the other layout managers, they’re great for portability to odd platforms (PDAs and such) but I agree that they are overkill and a huge nightmare to use.
Yeah im not even close to being objective. I love .net and hate java. When I write a program in C# it very often works the first time I compile it, where as in java I always have to spend hours looking at some trivial peace of code because there is always something in the java class library thats implemented in some incredibly wierd way.
Um … maybe you should write your apps by reading the specs first instead of *guessing* as to what they are – also, Java is relatively consistent, although I agree that the Calendar classes are a huge overbuilt disaster – not fun to work with (but, of course, incredibly powerful, flexible and localizable.)
And I like working in an IDE that doesnt eat up my entire RAM and doesnt eat up 100% of my CPU for no apparent reason way to often.
You’re right – Eclipse has been known to do it’s fair share of random freezes for several seconds. Hopefully this will be fixed in the 3.1 release.
>>>Um … maybe you should write your apps by reading the specs first instead of *guessing* as to what they are
javadoc is huge for every class and many of these wierd little pecularities are mentioned in some small part of the text, if mentioned at all.
If I need to know how to use a class in .net, I can find help very fast and its well structured. Most of the time I dont even have to look up a new class, because everything behaves exactly how you would imagine it would behave. That is a sign of a GOOD design.
Thanks for the FormLayout info. I admit I dont have any experience with SWT. I read a tutorial after reading the interview, then I tried to create a visual SWT class with Eclipse (+ visual editor plugin) and it threw out some wierd error.
aaa wrote:
> But one thing you said made me confused, why do you feel bad using Sun’s
> java? it is not piracy.
I just prefer using GNU or GPL’d software whenever I reasonably can. It may be possible to build/run jEdit with GCJ4, but I haven’t put in the time to find out yet (work has been crazy-busy lately, and promises to be that way for the next few weeks at least). I was just trying to be a little funny saying “I hate to admit it…”.
chemicalscum wrote:
> John fire up Jedit and reset the look and feel to GTK+ then look at the system
> fonts on the menus then compare to Firefox.
It hadn’t occurred to me that the font rendering would change when you change the LaF. I’d always just used Metal at home because I prefer it to GTK (yes, I *like* the way Metal looks
. I’ll have to try your experiment when I get home tonight.
I’m at work right now, and only have OS X in front of me ATM. When I switch to the metal LaF, jEdit only works for a little while and then eventually crashes or locks up or just starts acting weird.
Anyhow, it’s using Apple’s Java, and Apple is probably only concerned with their LaF looking (and working) good on their platform.
Yes though: I’ve tried Eclipse at home on Debian, and the fonts look great — just like Firefox, and just like the text editing area with Metal jEdit.
> As for the other layout managers, … but I agree that they
> are overkill and a huge nightmare to use.
Well, I always use “Layout Managers” even in the most simple Dialog. If you care to create your Dialogs with some sane GUI-Designer it’s not a problem at all.
I tend to prefer Glade and wxDesigner. (Those are not Java tools, but the concept is propably the same.)
I have not written a UI in years which was not resizable.
The standard JDK layout managers however either are too simplistic or syntactical nightmare overkill (Gridbag )
There however is one which solved most if not all of the standard needs you ever have, that one is the Formlayout by Kasten Lentzsch, possibly, the most powerful and almost easiest to use layout manager in existence.
Test