What's the deal with Swing?

[ross at indessed.com]

On Tue, 28 Mar 2006, "Ryan Bowman" wrote:
> I am curious - since we use it at work for our client-side app (I
> work on the web-side of our app (unfortunately, using Struts) I don't
> get to/have to use Swing - what's so bad about Swing?  People who like
> Swing are also invited to participate.

[Chapter 1: Swing]

Once upon a time, when the world was young and Java was the newest 
language around, there was a windowing toolkit named AWT. AWT basically 
sucked, and was ugly. Then there was Swing. Swing drew all of its own 
widgets by itself, line by line, inside of Java. Java at the time was 
pretty slow as it was, and the methods Java used to draw on its canvas 
were pretty slow as well, and all of this was running inside of a virtual 
machine ... so, as you can imagine, it was pretty slow. Clicking a menu or 
a combo box would result in a perceptible, if small, delay that made the 
UI a pain to use, especially on slower computers. Furthermore, Swing was 
ugly, although not so ugly as AWT. And no matter which platform you used 
it on, it was the same ugly. On Windows, it didn't look like Windows 
widgets, it looked like some sort of weird Motif-style widgets. Same on a 
Mac. On most platforms you couldn't even copy-paste between Swing widgets 
and the platform's widgets--Java maintained its own special clipboard.

Basically, Swing sucked hard.

Then Java started getting faster and more optimized. Sun started 
optimizing the drawing/canvas routines, too. Computers got faster. The 
widgets were redesigned to be prettier, and several different skins were 
available to choose from. Everybody (except I think Microsoft) fixed the 
clipboard issue so Java used the platform's clipboard instead of having 
its own special one. This was several years ago, and most people when they 
think of Swing think of this era.

Apple was the first to really jump in the swing of things (ha ha) with OS 
X. Apple wrote their own version of Swing that looked nearly identical to 
Aqua. They also (if I remember correctly) spent a good deal of effort 
making Java faster and more integrated with OS X. As a result, it was 
possible to create Swing apps that were nearly indistinguishable from 
native OS X applications. A Linux "look and feel" quickly followed suit, 
that was nearly indistinguishable from some default Linux skin (I can't 
remember which one, but pretty much nobody cared because Linux users are 
accustomed to having a different "look and feel" for every single 
application that they use). I can't remember what Microsoft was doing at 
the time, but it was probably something fairly crappy. I still don't think 
you can make your Swing app have XP-ish widgets today. Swing has been 
getting faster and faster (probably some to do with optimizations, and a 
lot to do with computers in general just getting faster). Today if you're 
running a Swing app on OS X or Linux, you're going to have a pretty good 
user experience. If you're running Swing on Windows, you'll still have a 
pretty good experience, but your app won't integrate well with the rest of 
the system--it will still be, quite obviously, a Java app.


[Chapter 2: SWT]

IBM was developing an IDE back some years ago, and thought that Swing was 
too slow. So they developed their own toolkit that hooked into the 
platform's native widgets. They called it SWT, the Standard Widget 
Toolkit. Basically, it's a bunch of Java wrappers to the underlying C/C++ 
code. The last major project I worked on used SWT, and I have very strong 
opinions about the toolkit. :)

But first, the positive--SWT applications look indistinguishable from 
native apps, especially on Windows. For the most part, users won't even be 
able to tell that Java is under the hood. It also feels faster (in terms 
of GUI responsiveness) than Swing according to some people, although I'm 
not always able to tell a difference.

However, SWT has its problems. First of all, it was developed to be a 
toolkit for Eclipse. If you want to do something with your GUI that 
Eclipse didn't need to do, chances are you're not going to be able to do 
it, or you're going to go mad trying. If there's a bug in the toolkit that 
doesn't affect Eclipse, it probably won't get fixed anytime in the near 
future. Furthermore, any documentation you find is probably going to be 
Eclipse-centric at best, and incomplete or missing at worst. (Swing really 
has great documentation.)

SWT also completely fails (in my estimation) at hiding the underlying 
layers from the programmers. Swing was built from the ground up using a 
very strong MVC architecture and solid OO design principles, and although 
you can spot mistakes here and there, the solid design really shines 
through. SWT feels very much like you're writing in C or C++.

SWT also does the "least common denominator" thing. If Motif doesn't have 
a particular widget but GTK and Windows do, SWT doesn't include it 
(generally speaking). As a result, some basic functionality is missing 
from SWT. You also run into some really weird things, for example SWT 
tables can have a checkbox in the first column no problem, but if you want 
a checkbox in any of the other columns you have to jump through all these 
hoops and heaven forbid you ever want to change what's in the other 
columns dynamically. In addition, because SWT uses the underlying widgets 
of the OS, the widgets may behave very differently on different platforms 
in surprising ways. For example, resizing a particular widget may 
automatically reflow the content on some platforms but not on others. 
Changing the content of a widget and calling a certain method might prompt 
a redraw on Windows, but with GTK might not. Look in the documentation for 
help trying to figure out which methods to call? Good luck, it's almost 
non-existent in this area.

But SWT is making progress too. Layers like JFace or SwingWT shield a lot 
of the crappiness of SWT from the programmer. As it matures and more 
people use it, the documentation is getting more robust and more people 
are willing to fix non-Eclipse-specific issues. SWT is shaping up nicely, 
but unless I *really* had to have Windows-looking widgets, I would use 
Swing over SWT in a heartbeat.


[Chapter 3: To Sum Up]

What's so bad about Swing? From a programmer's perspective, I don't think 
anyone has any complaints. (Please correct me if I'm wrong.) From an 
end-user's perspective, depending on the speed of your computer and what 
platform you're own, it may not blend well with native apps and may be 
somewhat less responsive than native apps. Also, a lot of people just 
don't like Java on the desktop for Java-specific reasons (usually JVM 
behaviors like eating memory for lunch or the slow launch time) rather 
than any Swing-specific reasons, and that's why they might speak harshly 
about Swing.

Hopefully that answers your question. ;-) If I've left anything out, 
please let me know!

 	~ Ross