« Declarative GUIs in Java, Lysol for Code Smells | Main | Groovy can give Swing a fresh start »

Groovy can save Swing

Groovy can save Swing. Well maybe, and maybe not. The real question in my mind is tools supporting Groovy Swing development. But for more of the substantive issues, Groovy can foot the bill. According to pinderkent JRuby cannot save Swing. This was a response to Julian Doherty's JRuby can save Swing, which itself was a response to an old post by Joshua Marinacci titled Swing has Failed. That's a lot of items to respond to, so for this post I will keep my comments to the first post, JRuby cannot save swing.

First, Kent brings up an oldie but a goodie, "Swing is Slow." At least he isn't pounding on Java is slow, that has academicaly been disproven years ago. The only problem left must be the API, and it is not the use of the API that makes many swing apps slow, but its abuse. The stock answer to this is always true: "bad programmers abuse the Event Dispatch Thread." Seriously, whenever anyone wants to start programming Swing someone else needs to get a stick and beat them until they write in blood the oath "I will not do data processing in the Event Dispatch Thread."

So how does Groovy make this simpler? It's closure syntax makes it less crufty to do things like process data in response to a button event. Check out one of my older posts on Groovy, Verbosity, and Swing to see how easy it is.

Kent's second argument is a red hearing. He complains about how difficult the swing API is. Let's look at another successful GUI toolkit: windows. We have the raw win32 APIs, then there is the MFC that got layered on top of that (or OWL if you are a Delphi fan) and then, yet another layer if you are up to date: WinForms. Lots of ugly confusing layers and arcane code. Lots of APIs are not a symptom of a toolkit that has failed, quite the contrary in most cases. I'd say it's a sign of maturity, and of a toolkit that people have used and that has evolved. You want simple? Go write web pages, just don't do anything complex, like AJAX, or CSS support across multiple browsers, or... wait. That stuff is just as big and confusing as Swing! Take your straw man and go home already

Finally, why is Groovy so much better in my opinion than JRuby for Swing apps? It's all about the syntax. Groovy looks like Java 95% of the time. In fact almost all Java code snippets can be dropped into a Groovy script without alteration. JRuby? You need to learn a new syntax, and ugly PERLisms like conditionals after statements. i.e. format_drive unless drive_has_useful_data, the problem being the "unless" portion can scroll off the right of your text editor so you can never see it. Swing programmers are used to seeing C based Java Code, and almost all Java code drops into Groovy quite nicely.

But none of this will matter unless we get better IDE support for Groovy. Sure, there is an eclipse plug-in for Groovy and Grails, and NetBeans has Coyote. But JetBrains has gone Ruby on Rails crazy and NetBeans is going down that path as well for NetBeans 6.0. It appears that tool support, and not completion of the JSR, will be Groovy's Alamo.

Comments (3)


Very interesting and informative post. Groovy does sound very cool, and if I were mainly a Java programmer, I'd be inclined to use it before Ruby.

However, your criticisms of Ruby seem weak. Learning its syntax is not hard at all. Any programmer should never be afraid of learning new things if the pay-off is worth it. (Not to say that Ruby is for everyone: Groovy may still be better for you.) If you don't like the unless clauses, don't use them. If you don't like lines that make you scroll, reformat them. And if you just don't like Ruby, feel free to use Groovy or Java or befunge if you want.

Danno Ferrin [TypeKey Profile Page]:

Syntax alone isn't the thrust of the criticism on Ruby's syntax. The ability to do drop in use of Java based code snippets for some Swing features was the main intent of it. Groovy is more compatible with the existing knowledge base of how to do things in Swing.

BTW, to the uninformed reader (like I was 2 minutes before posting it) Befunge is a legitimate language, that is if you grant that INTERCAL is a legitimate language as well.


Groovy looks like Java 95% of the time. In fact almost all Java code snippets can be dropped into a Groovy script without alteration.

That's my main concern with groovy. With each version the java language get more expressivity (even if you only consider java 5) so using another language which can give you only a 15-20% better productivity doesn't pay when you can get even more just using a world-class IDEs (eclipse, IDEA) and a nice framework. In an "enterprise" team, groovy doesn't pay.

To me, the real contenders in this field are jruby and jython (I don't know scala to adding it here) which can offer you more productivity gain than java plus some ide. They are "real world" languages too, they are mature as a language and you can leverage the know-how in non-java environments using its C conterparts. Unfortunately (for my taste, being a python guy), jython is advancing so slow that the only contender right now is jruby.

Post a comment


This page contains a single entry from the blog posted on February 20, 2007 4:03 PM.

The previous post in this blog was Declarative GUIs in Java, Lysol for Code Smells.

The next post in this blog is Groovy can give Swing a fresh start.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33