State of Swing
Saturday, November 29th, 2008
Last week during my JavaFX talk, a lot of good questions and comments about Swing came up. Hot off of a Swing project, I thought that it might be useful to compile some of my thoughts on the subject. So herein lie some common Swing sentiments that I feel are out there and my thoughts on them:
Isn’t it true that Swing is slow/ugly?
While it is true that Swing had a bit of a rough start, remember that it was coming from the world of the AWT which was slower/uglier. Another thing to keep in mind too is that Swing has been evolving right along with the core Java platform.
No doubt many tried it out eight years ago when it looked like this, threw up in their own mouths, and then went back to their VB 6 programming while listening to Spin Doctors on their mini-disc player.
Fortunately though, Swing has more or less kept pace with modern UI guidelines. As I humorously explored in my first post ever, the new L&F Nimbus rivals the sleek look of OS X.
That’s still mainline Swing though. If you’re up for a bit more of a experimental (but still Sun Sactioned) experience, you can turn to SwingLabs. Swinglabs is where many high quality libraries live that are not yet ready for prime time in a formal JRE release. But that doesn’t mean you shouldn’t use them.
Indeed, my project made heavy use of the SwingX componets which feature such gems as:
- Searchable/Filterable tables and trees
- Transparent components
- Intelligent “business level” components, such as a Login Dialog box
And no post about Swing is complete without mentioning Karsten Lentzsch and his JGoodies library. Karsten is one of the leading Java Usability experts and is an advocate for designing elegant User Interfaces (as opposed to say, allowing programmers to just put everything in nested panels which is mostly how I approached UI design in the 90s).
Swing can do more than just “form based” business apps of course. Check out Aerith to see what Swing is capable of.
Swing’s programming model is difficult to understand and/or overly bloated.
It’s true that it’s hard to do any Swing without bumping up against threading issues. Concurrency is a complex issue for sure. To paraphrase some quote whose author I can’t remember: “There is no such thing as bug-free multi-threaded code, just bugs that haven’t been found yet”. Fortunately there are several efforts underway to build higher-level frameworks on top of raw Swing.
The project I just finished up used the Swing Application Framework which does a good job at handling many of the unpleasantries of UI development such as:
- Providing a centralized task management system where you can submit background (non-UI) work for asynchronous execution, taking some of the pain out of concurrency issues.
- Handling basic application lifecycle methods, such as initialization and exiting.
- Supporting Action declaration via Annotations.
- Taking (most of) the pain out of resource management and I18N.
The Visual Builders I’ve used don’t work right.
I couldn’t agree more, so I don’t use them — this includes Matisse (or whatever it’s called now). I think visual development is fine for Proof-of-Concepts that will never see the light of day. But you really can’t maintain a UI through a visual builder. They’re unpredictable, not at all portable, and they take dumps all over your code.
I started writing this app in Netbeans and later switched to Eclipse for the Groovy support. Had I used Matisse (Netbeans) to build the UI I would have been screwed. “But wait!”, you say, “what about the matisse plugin for Eclipse?” You know what? Stop. Just stop.
Sorry, I know this is a hot topic for some, but I feel that when it comes to UI development, simple is beautiful. If something is so complicated as to require a visual builder, then it’s probably too complicated. Instead of visual builders, we need more expressive languages geared specifically to creating User Interfaces. I put that in bold, so…you know…think about it.
I do wholly acknowledge though that the Swing API is daunting. So what does a Java, but non-Swing programmer do if they want a UI? While this isn’t a JavaFX post, I would suggest that JavaFX aims to fill this hole by offering a more simplified, “streamlined” version of Swing. Swing-lite, if you will.
Groovy also has a similar DSL style support via SwingBuilder and GraphicsBuilder. In fact, why not write your entire application in Groovy?
Anyway, now back to the Spin Doctors…
3 Responses to “State of Swing”
Leave a Reply
Recent Posts
Archives
I’m Literate!
'to-read':
Tags
Categories
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Great blog. Makes me want to run back to Swing development and forget all this web crap.
I couldn’t say it better myself, why not write your whole application in Groovy? I hope you have continued with your use of Groovy Eclipse, and we on that team would love to hear feedback.
Still is there any UI API that anyone really likes? Aren’t they all a pain in someway or another? Personally, I kinda like the native look of SWT/JFace applications, but then again I am an Eclipse guy. But, who knows Andres may get me interested in Swing again with Griffon.
Having spent almost all of my time as a developer working with Swing, I’d have to say that I enjoy working with it for the most part. For all the apparent grumbling about Swing, I thought it was interesting to learn at JavaOne this year that the Ruby community has embraced Swing for UI work.