What's the deal with Swing?

Blake B. shadoi at nanovoid.com
Wed Mar 29 08:42:40 MST 2006

It cracks me up that the posts in a thread concerning java are some  
of the most verbose that I've read on this list in years.  I guess if  
you're used to coding like that, writing like that comes naturally.   
Not that this is a bad thing, just humorous. (to me)


On Mar 28, 2006, at 11:26 PM, Bryan Sant wrote:

> 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
> here:
> http://www-128.ibm.com/developerworks/java/library/j-tiger10194/
> 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
> "wrong".
>> 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:
> http://www.jgoodies.com/freeware/jdiskreport/index.html
>> * 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.
> -Bryan
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */

More information about the PLUG mailing list