SWT, Swing, or AWT - Which Is Right For You?

An anonymous reader writes "Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all, nor is there a one-size-fits-all GUI tool kit to be invented soon. Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience. Read descriptions of each tool kit's basic features, and the pros and cons of using each."

Comments

My six word summary

[MillionthMonkey]

SWT : buy
Swing: hold
AWT : sell

Re:Why is AWT even an option?

[roman_mir]

Oh, really? No reason at all? About a year ago, I had to work on a project for Christie Digital through Alt Software. The project was about building software that controlled video input from multiple devices into the same computer (I tested with 70 simultaneous inputs, this was possible because the hardware used overhead busses from input cards to output cards,) and video output onto rear-projector TV Video Walls. The software had to be designed in a way that supported multiple different platforms (windows/linux/unix.) So the front end was written in Java - this piece handled the windows, channels and profiles, it handled all the user interface issues. In the middle there was cross-platform C++ for video thread handling and resource management, and the back-end was all platform specific C code (basically device drivers from different vendors.)

So I did prototypes with Swing and found that there were problems with JNI Canvas handling. It wouldn't work properly but it did work with AWT. The Canvas had to be drawn in a specific color (magenta,) so that when the window handle was passed through JNI to C++, that code could pass the window handle further to the C drivers, that would draw on top of the magenta color within the window (on the Canvas.)

None of the above.

[seebs]

Buoy is your friend. It's built on top of Swing, but it's actually sanely usable. I recommend it on the grounds that it is the only Java GUI toolkit I have ever used that did not leave me longing for the sweet embrace of death. Developing an application using Buoy is substantially less painful then stabbing yourself in the eye with a fork. In the world of Java GUI development, this is high praise indeed.

Seriously, though. If you are doing GUI work in Java, but your actual goal is to get something else done, and you would like the GUI toolkit to take less than 80% of your development effort, use Buoy. It's not "dumbed down"; it's just SANE.

Swing

[Anonymous Coward]

I've never used SWT, but I have quite extensive experience in both AWT and Swing, as well as many other GUI toolkits, including two cross platform toolkits of my own for a commercial product that shall be anonymous in this post.

In my opinion the Cocoa AppKit on OS X is perhaps the most elegant overall. The problem is that with Cocoa AppKit, the common things are extremely simple and easy to do, but the more uncommon things can be quite tricky. With Swing, the most common things are still simple, but take considerably more code than with Cocoa. But when you get to something more advanced where you want to get some custom behavior (maybe dealing with drag & drop on some custom widget, or perhaps you want to customize the selection model on a tree widget or somethign similar), then Swing suddenly becomes much easier to work with compared to the otherwise simple Cocoa.

AWT isn't really an option over Swing in my opinion. It's there for historical reasons, and as the low-level API for Swing. Swing is built on top of AWT, after all.

There are a couple of larger problems with Swing:

1) Performance can suck if you don't know exactly what you're doing.
2) Making it behave exactly like you want often requires you to know it quite well.
3) It is quite large and complex, and can seem overwhelming to learn.

The performance problem is actually the biggest reason Java is still perceived as being slow by many people who aren't familiar with it. Developers often shoot themselves in the foot with threading issues, and it makes Swing UI's seem slow and poorly responsive. Also, because of poor understanding of the more advanced layout managers, it's also not uncommon to see Swing based UI's that just... look sort-of wrong. They don't look like native apps. Not because of look & feel issues of the widgets, but because of margins and paddings around widgets being wrong. You have problems like buttons being too large, text areas being right up to the edge of the window, quick-hack looking layout of widgets in preferences-style windows that have a large number of widgets, and so on. You often also see things like the app not painting itself during window resize drags, default window icons, inconsistent font sizes, and so on. Many of these are simply caused by people not fully knowing the Swing API and not knowing how to do things properly. It's not that you can't do them right, it's that people don't know the tool thoroughly. In my opinion, this is directly caused by the API being overwhelmingly large for many developers. While it gives Swing its incredible flexibility, it also indirectly is the cause for many of its problems.

Sun is tackling the performance problem from one end. They are working on accelerating a lot of the lower level graphics API (image drawing, primitive drawing, etc.) with OpenGL and DirectX. This helps a lot in many situations, but it doesn't help in the cases where people do 3 second tasks in a UI event callback method. Likewise, the ugly-UI problem is being helped by better IDE's (Matisse in Netbeans 5, for example) and by Java SE 6's (Mustang) better handling of system look and feels.

Still, there's a long way to go. But Swing is getting better every day, and it's the standard choice that works on all platforms, and it IS possible to do excellent UI's with it even today. You just need to learn it well. My recommendation is to read the API reference until you know it by heart. Then study the Swing source code to see how things work under the hood.

Re:System.Windows.Forms

[Anonymous Coward]

Then you'd probably like SWT. It falls to the least common denominator: Windows forms.
I don't know why anyone actually enjoys programming winforms. Do you like writing resize functions? Then changing them all the time?

Personally I'd take gtk over about any other toolkit. But of the ones in this article Swing is clearly the strong winner. The only thing I find horribly lacking in it is actually the listener mechanism. Having one function handle every event for an object is just messy when it comes down to it.

But, since Java doesn't support function pointers or multiple inheritance, implementing an action listener is about all you can do. And to do that, you have to only have a finite number of functions to make the user implement.

And for those obsessed with toolkit mechanisms from 1987, Swing supports a "null" layout manager, so you can just put crap wherever via pixel positions.

And, you might wanna realize that Microsoft is coming halfway to the modern world with WPF. They now support a dynamic resizing system, based on a tabular form for your widgets. They line up with each other, and are pulled to things. I guess gpu's are fast enough to calculate a spinning rubix cube with a different video on every side, but heaven forbid you write a real layout system ;).

And hence, you'll have resizing apps at the cost of almost no performance, and little learning. But unfortunately some of the widgets may look _really_ STUPID when you make the window very tall.
The point: Kiss winforms goodbye, you're about to get halfway to a real UI toolkit!

Maybe next they'll come halfway to a real HIG!

Swing is maturing, SWT has growing pains

[BortQ]

I give much credit to SWT for putting a fire under swing and forcing them to improve. The current Swing is much better then it was a few years ago. It can take some long years before a toolkit matures and best practices for its use come out. I feel like that is happening now with Swing. If some of the SwingLabs stuff gets put into the real pipe that would be lovely.

SWT seems to be encountering some growing pains as it really starts to cover everything that a toolkit must. I wish them luck in pulling through even stronger (on all platforms please). SWT certainly has had a strong start.

It seems like there are enough Java developers out there to support 2 GUI toolkits. I think in the long run this can only be good for Java as a whole. If people don't like one they can stick with Java and swap out the toolkit. If one eventually becomes "the one" then it will only be because the other pushed it to be the best it could.

Question

[Orlando]

This may be a dumb question, but why can't Java just provide access to the existing desktop GUI (Windows, OSX, QT, whatever) rather than re-inventing the wheel with it's own set of widgets that inevitably don't look or behave like native apps?

Re:Question

[archeopterix]

A "middle way" is to do what SWT does and wrap the native widgets with a generic API. This creates a "lowest common denominator" problem, however, since you inevitably have to stick to only using those widgets which all your target platforms have...

This "inevitably" is the consequence of forcing the full cross-platformness down the developer's throat. Yes, if you create One API and force the programmer to use it, the "lowest common denominator" problems are inevitable. But this isn't the only way. I use wxWidgets for my GUI apps. I can stick to the cross-platform API when I want a quick cross-platform GUI, but I can easily take advantage of the platform-specific hacks - they're just one GetHandle() call away. And my app can still be cross-platform, at least as long as I check the current platform before calling win32 or gtk-specific functions.

Re:Is none of the above an option?

[Anonymous Coward]

Pick something besides AWT/Swing, and your users need to download and install it.

Or they just get screwed. AFAIK there's still no 64-bit version of SWT on Windows. If you want an SWT application to work on x64, you have to install the 32-bit JVM. :(

Too many freakin' guis

[borgheron]

This is the trouble with Java.. there are too many GUI libraries. Standardize on one and forget the rest. It seems that when an environment is born without one, it's destined to search for the perfect gui framework forever.

As an example of an evironment which has never had this problem, take Mac OS X, it has had AppKit since the day it was created... and it will never see another major gui framework. Ah, yes... you can say but there's GTK and others available on the Mac, but they are not a threat to the *MAIN* AppKit framework... (they do, in fact use AppKit, so they aren't an outright replacement).

Intersting dilemma...

But... to get back on topic, I prefer SWT, it's faster, and it blends more readily with the native environment than the others.

GJC