What's the deal with Swing?

Bryan Sant bryan.sant at gmail.com
Wed Mar 29 00:26:21 MST 2006

On 3/28/06, Dave Smith <dave at thesmithfam.org> wrote:
> ross at indessed.com wrote:
> I learned Visual Basic years ago, then AWT, then Swing, then Borland
> Delphi, then SWT. Then, I picked up Qt. I've been coding in Qt (in C++)
> at work for about a year now, and I love it. Qt is the greenest GUI
> pasture I've ever played in. Swing is the worst. Let me elaborate:

Qt is awesome.  The best UI toolkit in the world for sure.  Too bad
it's GPL or $2,500 per developer seat.  :-(

> Qt got it just right by providing an excellent graphical GUI builder that
> actually works!

Having had used Qt Designer, I know what you mean.  It is awesome. 
But the new Netbeans GUI builder is EVEN BETTER in my opinion.  Forget
about any Swing GUI builder you've used in the past -- I can't say
enough good things about this new builder.  So, yes Swing's API is
verbose, but with the Netbeans GUI builder you write very little UI
code.  Just drag-n-drop like you did in VB/Delphi/Power Builder/Qt
Designer, double click on a widget and write the snippet of code.

> * Hard-to-use layout managers.
> One word: GridBagLayout (wait, was that 3 words?). I dislike Swing

Ick.  No kidding.  GridBagLayout is a nightmare.  The only reason I
ever learned that was to pass the Sun Certified Java Programmer exam. 
I've never used it in a real app.  Thankfully, the JCP has gotten the
message, and now we have GroupLayout and the Netbeans GUI builder to
replace it.

But honestly, other than GridBagLayout, I think the Java layout
managers are helpful and easy to use.

> layout feedback wastes too much developer time. SWT got it slightly
> better with FormLayout, which I found very useful. Then I discovered
> Qt's layouts: horizontal, vertical, and grid. That's it. Super simple.
> Qt got it right, because widgets know how they are supposed to stretch.

Mustang's GroupLayout (used by the Netbeans builder) is even better. 
Also Java's BoxLayout works like Qt's horiz and vert layouts.

> * Cumbersome Deployment
> Since we're talking about desktop applications, we have to mention
> deployment. Java desktop applications are hard to deploy. I think Java
> WebStart is pretty nifty, but it requires a JVM to work! My experience
> porting from Java 1.3 to 1.4 was painful enough to teach me that Java
> apps would have to ship their own JVM (meaning they would never be able
> to adapt to the already installed JVM at runtime). That's sad, because

No.  As long as someone has a 1.5 or better JVM, the JNLP descriptor
will tell them that they need a newer JRE to run your WebStart app (if
you require a newer JRE) and the older JVM they have will know to
download the newer JVM to run your app (with the user's permission).

> the JVM is huge, even by today's standards.

16MB.  I'm not saying that it's small, but the .NET 1.1 runtime is
22MB -- .NET 2.0 will be even bigger.  It would take your averge user
less time to download the JRE than it would for them to do their
monthly Windows update...  Or daily virus scan...  You choose. 
Downloading Firefox and Thunderbird takes 10MB.  So I disagree that it
is big by "today's standards".

> I used InstallAnywhere to deploy my Swing app at work, and that thing took 30 minutes just to
> build the installer. Now I use Nullsoft's NSIS, which takes about 3
> seconds to build my Qt GUI's installer. All I do is install the 2Mb Qt
> DLL on Windows and I'm done. If I don't have that liberty, then I

You can stil use NSIS with Java apps.  I would.  I hope you're
distributing the Qt DLL legally.  Either you've paid Trolltech $$ or
your program is GPL right?

> statically link the whole executable (which works fine on Windows and
> Linux), and I have zero dependencies! Zero!

That is sweet.

> * Swing is ugly by default

Java's new default ugly theme is less ugly that the old default ugly
theme :-).  With Java 5 and better the default theme is "Ocean".  See


The top screenshot is the old default and the lower screenshot is the
new default.  This is just my opinion, but I think that most users
would find that lower screenshot to be attractive and usable.

> Last I used Swing, it was still "ugly by default." What I mean here is
> that Swing requires some heavy tweaking to make it look decent.

This is not true any more.  You do, as a developer, have to set the
look and feel to be "System" as a command-line arg or in your Swing
code at startup.  But once you use the System look and feel, the app
looks like all other Windows apps.  On Linux you're still screwed
until 1.6 ships and GTK looks good.  But hey, choose another look and
feel for Linux then:

Choose here:  http://www.javootoo.com/

Who wouldn't want to use napkin look and feel :-) ?

> Qt, on the other hand, is pretty by default. I don't have to choose styles, or
> subclass buttons to make my Qt GUIs look nice. SWT is pretty darn good
> in this respect too, but Qt is by far better.

Qt does look good by default.  But just for the record, you know that
Qt is doing exactly what Swing does.  It emulates the native look and
feel (draws its own widgets).  SWT is literally using native widgets,
so SWT is "right" and both Qt and Swing have the possibility of being

> It is hard to use JCanvas. I've found QCanvas to be a delight to work
> with, even with very complex display/interaction. QCanvas supports
> animation, velocities, and double-buffering out of the box. Every object
> you create on a QCanvas knows how to draw itself, and you can reposition
> them with a single line of code, without having to worry about all the
> other items on the canvas. JCanvas doesn't provide such a powerful API.

I don't follow.  At least in Java 1.5 and better JCanvas is
double-buffered and it has always known how to draw itself.  This is a
common UI composite design pattern.  I may be wrong (because I haven't
worked with QCanvas), but I bet their API and capability is nearly
identical.  If you want to see some cool things done with JCanvas
launch this with 1.5 or 1.6:

> * Swing is slow by default

You mean the *preception* is that swing is slow because people run
blocking code on the the even queue thread.

> It's bad to do heavy lifting on the event thread. Every GUI developer
> knows this. Swing makes it hard to avoid though. So they invented the
> invokeLater() hack, which ends up filling your code with anonymous
> instances of Runnables (Runnable is pretty cool, though), which still
> get run in the event thread, just a tiny bit later, resulting in a slow
> GUI. On the other hand, all of Qt's API is non-blocking. That means you
> can call QSocket.connect() and it will immediately return. The QSocket
> will notify you when it's done. The same is true of all of Qt's classes.
> In Swing, you would have to code all that infrastructure yourself.

Java 1.6 has SwingWorker that solves this problem, but an even better
solution is spin (http://spin.sourceforge.net/).

Qt did do it right out of the box though.  I'm not saying that Swing
is on par with Qt, but the two are pretty close in terms of concept
and ease of developerment (with Netbeans GUI builder).  My turn off
with Qt (it does have Java bindings) is that I have to pay $$ if I
want to ship something that isn't GPL.  Java is free (as in movie
tickets) regardless.


More information about the PLUG mailing list