Sun and Eclipse part 2: Getting past SWT vs. Swing

This is a continuation of yesterday's discussion, "Sun ready to join Eclipse, part 1". If you haven't read that one yet, then this one won't make any sense. So go read that one first. Go on, I'll wait...

Welcome back."SWT was a way to wake up the Swing team" Now let's break down Sun's "conditions" for joining Eclipse to see if they're actually possible or not. I'm going to present them in the reverse order from the way Tim Cramer gave them because I think it reflects their true priority within Sun.

#1: SWT vs. Swing

I know, you're saying "Not again!", but bear with me. Dozens of articles have been written over the years concerning these two widget sets but at their core, they do the same thing - enable Java code to display rich interactive user interfaces. Tim writes:

The reasons for SWT were understandable in the beginning but meaningless now.... SWT was a way to wake up the Swing team to the fact that GUI performance was awful. The Swing team has done a tremendous job of improving performance, and it's a standard.

While some conspiracy theorists still believe that SWT was some kind of evil plot to fracture the Java community, Tim recognizes here that there were perfectly valid reasons for SWT to be created. There's also an acknowledgment that SWT's existence has forced Swing to improve greatly in recent years. And while Swing isn't technically a standard, it does come as part of the JRE, so any improvement is good for Java. Ergo, SWT was a good thing for Java.

But does that hold true today?This whole SWT/Swing spat shouldn't be allowed to poison the relationship between Sun and Eclipse any longer. The performance difference between SWT and Swing has been diminished, and in some cases reversed. SWT still enjoys better support of native OS features, for example it was first to provide anti-aliased text support. But Swing has a lot of features that SWT (and it's model-friendly wrapper, JFace) is missing. For example, Swing's table and tree support is currently much more flexible, and it supports multi-row tabbed folders, sideways tabs, and MDI (Multiple Document Interface), to name a few.

Then there's this whole resolution-independent GUI can of worms that is going to be opening up soon as display resolutions exceed 100dpi. Windows Vista native .NET controls support a variety of vector-based solutions and highly flexible controls that would require a significant investment to expose in SWT. Swing is part of the way there already because it has complete control over the way things are drawn.

In the end, I think there are compelling arguments for SWT to continue in some form. The SWT programming interface is simpler and more approachable, it uses less memory, and it can target some platforms (like mobile devices) that Swing currently can't. Also, SWT has the advantage of being open source, while Swing is only semi-open and thus its uptake is limited in certain situations like Linux distros (but that may be changing).

That being said, the reason I keep dragging up this issue is that I believe this whole SWT/Swing spat shouldn't be allowed to poison the relationship between Sun and Eclipse any longer. There are just too many strategic reasons for these two organizations to get along. So what can be done?

Politically, I have no clue. But technically, two ideas have been put forward for addressing this issue. The first is to use SWT to replace/supplement AWT, the Ancient Widget Toolkit that underlies Swing. (Ok, that's not really what it stands for, but most Java developers would agree it's getting kind of long in the tooth).

Think about it. If SWT were included in the JRE (perhaps as a JSR, perhaps as a java.net project like JDIC), programs that used it could then be called "100% Java". So I asked Tim about this idea. At first he dismissed it, but when pressed he elaborated:

I don't know, I'd have to talk to the java team more in depth, but all this would do is create more engineering work for something of extremely limited value. I don't know why I'd want SWT to be part of the mix, it would send a strange message to the java development community (my opinion only).

Personally, I don't think it's either of extremely limited value or would be a strange message. As one commenter to part 1 wrote, "AWT is very limited: SWT could become a logical extension of AWT, its 'migration path'". Java client guru Scott Delap writes: "If Sun really wanted to cooperate [they would] concede and just offer SWT as a part of future releases of JSE as 'AWT 2.0' with the engineering support coming from Eclipse." So, this option is not totally out of the question, but there would have to be some definite value shown in order to undertake the work.

The second alternative is to port SWT to run on top of Swing, just like it has been ported to run on top of Win32 and GTK and Carbon. There's a little known project called SWTSwing that aims to do just that. If the Eclipse IDE could be shown running under something like this on top of Swing, and doing so just as well as native SWT, it would go a long way towards assuaging fears of SWT-backers about using Swing. The SWTSwing project is clearly in need of some help, but it might make a good migration path. So what was Tim's take on it?

That's a great start. I'm happy to see that there's a recognition of this being important.  Hopefully there isn't a severe performance penalty for using it (or we're back to square one).  Also I'd hope that they can cover and map all the APIs, though I'd imagine there's going to be some level of porting that needs to be done.

It would be a lot of work to get this kind of solution into production shape, but it's the kind of thing that Sun could help out with. 

One thing is clear to me though; for either of these ideas to work, Swing would have to become truly open source. There are just too many bugs still in Swing that need to be fixed and too many things (like desktop integration) that SWT currently does better. Sun's new management is trying to be more efficient, so here's one way - leverage the power and enthusiasm of the open source community in one of your most difficult areas.

Well that's enough for today. The next installment will cover the other two conditions and then delve into why I believe this partnership would benefit both organizations and the Java community as a whole.