Java Champion / JavaOne Rockstar Adam Bien (adam-bien.com) is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Would Someone Consider To Use SWT (or another native widget library) Again These Days For Portable Platforms / Applications?

06.23.2008
| 14062 views |
  • submit to reddit
Everything started with AWT in JDK 1.0. It came with JDK 1.0, and it used (actually uses—is still there) native widgets for rendering. I still remember the excitement, as it was introduced around 1998 (with JDK 1.2). Everyone was excited, although even the JTextFields weren't rendered correctly. Swing took the opposite approach—it rendered the components itself—so it was somehow OS independent. Only about three years later Eclipse was introduced with the SWT. It took a similar approach to AWT—because of the responsiveness problems of Swing and the native look and feel. At the time it was a viable solution for a given problem (although e.g. the performance of other Swing applications was really good). These days the responsiveness of Swing is just phenomenal (just ask IntelliJ / NetBeans users about it :-)), and Eclipse (forms) look very different to the native Windows applications (Outlook, Office, OneNote etc.). The new platforms like Flex, Silverlight, even Java FX, do not even try to achieve a perfect, native, look and feel—many nice demos just look totally different (which can be a good thing).

A native UI toolkit is harder to maintain for different platforms, because you have to test different operating systems (32 and 64 bits), and emulate some widgets, since they are not available for every given platform. So there is more effort to achieve the same goal (a decent toolkit). Furthermore, SWT can only wrap existing native widgets, so the usable API is somehow limited. It's not always fun to work with it. Just ask a developer (after a beer) with SWT / JFace experience, whether he/she really enjoys it. You will get interesting answers... :-).

Regarding the maintenance overhead and portability issues—it remains a really interesting question. Would e.g. Eclipse start with SWT again—or provide a lightweight alternative approach?

From: http://blog.adam-bien.com/

References
AttachmentSize
toolkit.jpeg4.17 KB
Published at DZone with permission of its author, adam bien. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andrew McVeigh replied on Mon, 2008/06/23 - 5:00am

i think it is interesting to note that SWT was really the latest in a long line of GUI toolkits built by Steve (and possibly Caroline?) at OTI. The earlier ones were all in smalltalk. They have a philosophy about how these things should work which has its roots back in the Envy native widgets versus VisualWorks emulated widgets.

i think the answer to "would they have still made SWT if swing was as good as it is now" is probably, although obviously i'm just guessing. I love swing (programmed in it for ages) and particularly Java2D, but i'm glad to have SWT in my toolbox also. it looks fantastic on most platforms, and is very lightweight.

the drawback of course is that we have 2 relatively incompatible toolkits. i spend a reasonably amount of time trying to make my (large) swing apps look like eclipse, rather than being able to easily integrate into eclipse ;-(

the other side of the coin is "would swing be as good as it is today without SWT to raise the bar?"

Cheers,
Andrew

Andrew McVeigh replied on Mon, 2008/06/23 - 6:06am in response to: adam bien

But Flex, Sliverlight etc. influenced the Swing development probably as well.

Hmm, not sure about that. Swing's API has been more or less the same for about 8 yrs now.

Another interesting thing would be the unification of SWT and AWT - and run Swing on top of it.

Many things are technically possible, in both directions. However, politically, it's another story ;-) ;-)

http://swtswing.sourceforge.net/screenshots/
http://swingwt.sourceforge.net/

But I think you are right -- unifying SWT and AWT would be a nice way to go if they wanted to unify the 2 sides.

Andrew

 

 

Jacek Furmankiewicz replied on Mon, 2008/06/23 - 6:16am in response to: Andrew McVeigh

I like the Swing API...but it looks so bad on GTK+/Linux (glaring UI issues + really poor font rendering) that I am very grateful for SWT. At least some Java apps look as good as GTK+ native apps....thanks to SWT.

In particualar, font rendering under Linux is HORRENDOUS for Swing apps...I was looking at the same file this morning in Eclipse and in a Swing app and it was just painful to even compare them.

I think Sun should use native font rendering in all the native L&Fs (Windows,GTK+,etc) instead of the default Java font rendering.

 

 

Andrew McVeigh replied on Mon, 2008/06/23 - 6:28am

In particualar, font rendering under Linux is HORRENDOUS for Swing apps...I was looking at the same file this morning in Eclipse and in a Swing app and it was just painful to even compare them.

Swing apps don't have to have ugly fonts, although it's fairly easy to leave it ugly ;-)

These are some pictures of one of my Swing apps under ubuntu:

http://dock.javaforge.com/screens/image_07.png
http://www.doc.ic.ac.uk/~amcveigh/images/stereo-evolution.png

I think Sun should use native font rendering in all the native L&Fs (Windows,GTK+,etc) instead of the default Java font rendering.

I think they were/are headed this way. As you probably know, the Substance LnF has a plugin to allow this: https://substance-bramble.dev.java.net/

It's pretty cool ;-0

Andrew

adam bien replied on Mon, 2008/06/23 - 6:34am in response to: Andrew McVeigh

[quote=andrewm]

Hmm, not sure about that. Swing's API has been more or less the same for about 8 yrs now.

[/quote] 

Sure - but from non-functional perspective it has. Java 6 update 10 makes it interesting again - without API changes. Java FX Script could become even more interesting as decorator / builder.

Jacek Furmankiewicz replied on Mon, 2008/06/23 - 6:34am in response to: Andrew McVeigh

How did you get such fonts under Ubuntu? I have all the sub-pizel anti-aliasing ON, so my GTK+ fonts look great...but the Swing ones are pretty painful. Is there any particular switch or something that needs to change?

Jacek Furmankiewicz replied on Mon, 2008/06/23 - 6:36am in response to: adam bien

I don't think so. There is so many things wrong with JavaFX that I don't even know where to start (everything from why didn't Sun just enhance pure Java instead to where is any decent JavaFX development tool for Eclipse?).

Andrew McVeigh replied on Mon, 2008/06/23 - 6:41am in response to: Jacek Furmankiewicz

How did you get such fonts under Ubuntu?

Hmm, it's been a while I'm not 100% sure what I did. I guess I could start removing stuff until it gets ugly again ;-)

Do you have the msttcorefonts ubuntu package loaded? It's a free set of true type fonts that MS donated years ago. They look great. I can't stand linux without them. I have the anti-alias set to LCD, but even without that it looks ok. Do you have a screenshot of the bad rendering so we can see?

Andrew

p.s. for the LnF, I use www.jtattoo.net and set all of the fonts to Arial. I can send you the code if you want. However, even the Metal LnF fonts look quite nice (except for the horrible bold menu text, but that's another story).

 

Jacek Furmankiewicz replied on Mon, 2008/06/23 - 6:43am in response to: Andrew McVeigh

I'll try to post something later today when I get back to my Linux box.

Neil Bartlett replied on Mon, 2008/06/23 - 7:02am

 

Oh boy, I can't believe I'm about to wade into yet another SWT vs Swing debate... I wonder how many more years this one is going to run? Can't we just "live and let live" and stop declaring the other side dead already? Anyway, here goes.

SWT already is the lightweight alternative choice. You emphasize the difficulty of maintaining a native UI toolkit. Why do you care, if you're not working on the SWT team yourself? How about the difficulty of maintaining a toolkit such as Swing with a vaguely native look and feel? Sun put a lot of effort into emulating the look and feel of Windows XP and Vista in Swing, and Apple put a lot of effort into making Swing feel more Mac-like. So what? All this maintenance is done by somebody else, so we can just use libraries that work.

SWT is still a great choice for new applications. It's the only GUI API that offers a strong abstraction over multiple lower-level widget toolkits, which means it has potential to grow well beyond its original purpose. These days there is really no such thing as a native widget library, at least not a single one per platform. Windows has Win32 and now WPF, Mac OS has Carbon and Cocoa, Linux has Gtk and Qt and more. This is why even so-called "native" applications like Outlook or Office don't really look native any more. But all these platforms also have have web browsers with AJAX and Flash capabilities. The Eclipse RAP project has taken the SWT API and wrapped it around an AJAX framework (Qooxdoo), which means we can develop UI components that are portable across both "rich client" and web-based clients. A big part of the exploratory work in Eclipse 4 at the moment is about web UIs. Going in the other direction, SWT will work on far smaller devices than Swing is capable of working on, essentially because it reuses the widget toolkit already on the device rather than ignoring it.

Finally just one minor point I'd like to make. I develop with SWT/JFace and yes I do enjoy it very much, both before and after beers! The API is more logical and easier to work with than Swing. You give the impression that everybody using SWT hates it, but I don't think it would have anything like its current popularity if that were the case. Oh and I don't think the responsiveness of Swing is "phenominal". It's acceptable, which is a big improvement over where it was when SWT started. By all means go ahead and use Swing, but I and many others will continue to choose SWT for new applications.

 

Michael Bien replied on Mon, 2008/06/23 - 7:23am in response to: Jacek Furmankiewicz

I am actually pretty happy with the fonts on ubuntu too:

http://people.fh-landshut.de/~mbien/nb.png

(NetBeans was started with java6 update 10 sdk)

make sure you have installed the sun-java6-fonts package of the "propretary" sun-java6 release (not openjdk).

Michael Bien replied on Mon, 2008/06/23 - 7:45am in response to: Jacek Furmankiewicz

@Jacek

please don't confuse JavaFX with JavaFX Script. Its similar to mixing java-the-platform with java-the-language. JavaFX is an acronym for making java usable on the desktop again which manifests in several apis, the upcomming java desktop profile and even projects like tiered compilation for the JVM. Update 10 is only the first step.

(no comments on JavaFX script ;))

Jacek Furmankiewicz replied on Mon, 2008/06/23 - 7:54am in response to: Michael Bien

If you call them the same it's easy to get confused :-)

Let's recap then:

JavaFX the platform: good!

JavaFX the language: forget about it. Sun, focus on enhancing core Java instead instead of forcing a new language no one asked for in the first place.

 

Jess Holle replied on Mon, 2008/06/23 - 8:22am

The technical underpinnings of SWT appear to be >90% hindrance at this point. Everything SWT-basd fails to work with Java 6 on OS X.  Why?  Native library issues.

SWT provided a good kick in Sun's pants to improve Swing.  They made it faster, better looking, added a plethora of convenience APIs.  At this point Swing works rather well everywhere without native library baggage -- and SWT just doesn't.

SWT's easy bridge to allow insertion of additional native components is nice when needed.  To retain this and its API style, SWT should be redone without any native libraries (apart from a purely optional one for plugging in native components) and with better Swing interoperability.  Right now its just an compatibility/portability issue as I see it.

Thomas Mäder replied on Mon, 2008/06/23 - 8:23am in response to: Neil Bartlett

What Neil said. Thanks Neil for this excellent post.

adam bien replied on Mon, 2008/06/23 - 8:43am in response to: Neil Bartlett

[quote=njbartlett]

Oh boy, I can't believe I'm about to wade into yet another SWT vs Swing debate... I wonder how many more years this one is going to run? Can't we just "live and let live" and stop declaring the other side dead already? Anyway, here goes.

[/quote]


Did you actually noticed, that your comment was slightly longer, than the actual post ? :-). 

I just thought about native and lightweight toolkits, and whether I would use one, or another, in case I would start from scratch and build a platform (and not an application on a platform). I actually do not care about the maintenance efforts of SWT in particular, rather than considering both approaches from the architectural point of view.

[quote=njbartlett]

You give the impression that everybody using SWT hates it, but I don't think it would have anything like its current popularity if that were the case.

[/quote]

 

I just asked some developers - and no one seemed to love it. SWT gains the popularity, because of Eclipse, OSGI and the platform in general, not because of itself. 

 

 

Btw. I do not drink beer during development in general :-).

adam bien replied on Mon, 2008/06/23 - 8:52am

I just changed the title to the origin: http://www.adam-bien.com/roller/abien/entry/would_someone_use_swt_or

I just noticed, it was somehow changed. Sorry for that.

Zviki Cohen replied on Tue, 2008/06/24 - 8:22am

The target market for SWT is enterprise desktop applications. The consumer market was never Java oriented. The enterprise market will not be quick to jump on the Flex/Silverlight/JavaFX bandwagon - it's more conservative since there's a lot at stake. SWT has a good head start in this market since there's a lot of investment in Java. Plus, the enterprise market technological directions are largely guided by major consulting companies like IBM (major player here) and we know that IBM is backing Eclipse/SWT (check out Lotus Symphony).  

There is another key component in this equation and that's Enterprise web 2.0. The enterprise is gradually moving online. However, the rules are different here. Browser compatibility is less of an issue than mobile devices support, so DHTML is not the obvious choice. The battle hasn't reached the peak yet. Eclipse 4.0, if architected correctly, has a chance of capturing a  share here (again, because of the Java investment and the IBM involvement).

My $0.02.

Zviki Cohen

Dmitri Trembovetski replied on Tue, 2008/06/24 - 5:26pm in response to: Jacek Furmankiewicz

> In particualar, font rendering under Linux is HORRENDOUS for Swing apps...I was looking at the same file this morning in Eclipse and in a Swing app and it was just painful to even compare them.

Screenshots, please. And the version of Java you see this on, too.

> I think Sun should use native font rendering in all the native L&Fs (Windows,GTK+,etc) instead of the default Java font rendering.

Starting with 6u10 on Windows we do use GDI font rasterizer. 

On linux you could use the openjdk6 shipped with some distributions and enjoy the "native" rasterization done by freetype font rasterizer integrated into openjdk. Sun's binaries still use t2k font rasterizer.

Dmitri

Java2D Team

 

Geertjan Wielenga replied on Wed, 2008/06/25 - 1:04am

I've been using Linux for several months now (Ubuntu) and have had no problems with the look of Swing at all. I'd like someone to explain what's so "horrendous" about Swing on Linux.

Jacek Furmankiewicz replied on Wed, 2008/06/25 - 6:57am in response to: rouletteroulette rouletteroulette

Hm, the image does not show up any more, try this direct link instead:

http://picasaweb.google.com/jacek99/Misc/photo#5215443663065775330

Jacek Furmankiewicz replied on Wed, 2008/06/25 - 10:34am in response to: Dmitri Trembovetski

OK, I guess what is horrendous to me is that none of the Swing fonts seem to pick up anti-aliasing and subpixel aliasing in particular. They just look "normal" without any type of antialiasing enabled.

Trust me, once you spend the whole day looking at native GTK+ fonts the Swing ones stand out like a sore thumb, it's not a subtle difference like on Windows.

And even when I tried OpenJDK (which supposedly uses freetype) it showed up poorly like this as well.

But thanks for the Font2DTest hint, I will try it and let you know.

P.S. One of the sore points of the GTK L&F is how badly the combo boxes are rendered. When I tried OpenJDK they actually looked pretty OK...does this mean OpenJDK has already some bug fixes that are not in the core Sun JDK?

 

Dmitri Trembovetski replied on Wed, 2008/06/25 - 10:50am

> OK, I guess what is horrendous to me is that none of the Swing fonts seem to pick up anti-aliasing and subpixel aliasing in particular. They just look "normal" without any type of antialiasing enabled.

You should use some zoom tool to zoom in on swing text. It _is_ LCD antialiased on your screenshots and yes, Swing does pick up the desktop settings for text antialiasing. It's just less fuzzy than gnome's.

> P.S. One of the sore points of the GTK L&F is how badly the combo boxes are rendered. When I tried OpenJDK they actually looked pretty OK...does this mean OpenJDK has already some bug fixes that are not in the core Sun JDK?

As mentioned above OpenJDK uses freetype library for font rendering, the same as Gnome, so they should look pretty much the same.

Dmitri

 

Michael Bien replied on Wed, 2008/06/25 - 10:55am in response to: Jacek Furmankiewicz

[quote=Jacek]P.S. One of the sore points of the GTK L&F is how badly the combo boxes are rendered. When I tried OpenJDK they actually looked pretty OK...does this mean OpenJDK has already some bug fixes that are not in the core Sun JDK? [/quote]

yes there are many GTK related bugs fixed in the OpenJDK6/7 branches. This particular one has been fixed recently, I think it was OpenJDK6 (in fact the combo box button wasn't rendered at all ;) ).

 [edit]

http://bugs.sun.com/view_bug.do?bug_id=6624717

Jacek Furmankiewicz replied on Wed, 2008/06/25 - 11:28am in response to: Michael Bien

Cool! So...how does this get rolled back into the regular JDK? Does Sun take fixes back?

Dmitri Trembovetski replied on Wed, 2008/06/25 - 11:33am in response to: Jacek Furmankiewicz

This was a Sun fix, there's nothing to "take back". The fix is already in JDK7 and OpenJDK7, it just got back ported to openjdk6 train afaik.

Dmitri

 

Michael Bien replied on Wed, 2008/06/25 - 12:22pm in response to: Jacek Furmankiewicz

This is a very good question Jacek,

Is there a process which tries to synch all bugfix efforts between the 3 main java distributions?

This is acutally my main fear regarding the openjdk branches. I asked it in the java.net forums some time ago but I haven't got a answer. (http://forums.java.net/jive/thread.jspa?threadID=41767&tstart=30)

And I am not the only one who thinks this could lead into problems (write once, debug... you know what i mean).

(and no I think TCK is not the answer to this question because it is not possible to verify every bugfix with a automated testcase)

Dmitri Trembovetski replied on Wed, 2008/06/25 - 12:54pm in response to: Jacek Furmankiewicz

This is no different from how the fixes propagate into different versions of the JDK.

Typically it is first fixed in the current release being developed. That would be JDK7/OpenJDK7 (remember, JDK7 _is_ openjdk7) now. Then if the fix is found to be important enough and the risk factor is not too great it may be backported an update of earlier releases (6u10 or whatever). openjdk6 is something of an odd standing "release". It is based on openjdk7 code with new apis added in 7 removed. So currently a fix could be backported to openjdk6 or 6uN or both. Fixes that go into 6uN (the "official" Sun's binaries) are scrutinized much more so some fixes (like something that may help a particular linux distribution) that may be go in openjdk6 may not end up in openjdk6 but mostly we try to make sure a fix gets into both - but they may not become available at the same time (we can't just stick a fix into the closest to released 6uN release - there's a train of those).

The situation with openjdk6  is temporary as starting with JDK7 both Sun's jdk and openjdk7 will be built from the same source.

Dmitri

 

Jacek Furmankiewicz replied on Wed, 2008/06/25 - 12:58pm in response to: Dmitri Trembovetski

thanks for the explanation, that clarifies things a lot. Cheers, Jacek

adam bien replied on Wed, 2008/06/25 - 1:17pm

Hi all, I'm using Vista, and Swing just looks and performs great (transluency etc.). Perhaps it is the right time to install a real operating system? :-)

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.