So I tried to implement one of my little Swing Utility ideas this weekend in Groovy. I need the utility and I thought it would be good to give the scripting language a go beyond simply using it as an interactive console onto the Java SE API. This is what I have learnt so far.

Well first off having an IDE helps. I used Smultron on OSX as it is an open source editor. Usually I use Komodo Edit for scripting and man have I become lazy about closing my brackets and braces. Probably the number one issue with my syntax.

I like to have a book to hand when learning a new language and in this case I have been using Groovy In Action. It is a good book and certainly seems to fulfill the role I have when learning something new. It is concise enough to allow me to jump to a particular topic when stuck on a particular point but also seems to have been written in enough of a structured narrative to give a context to what is going on when you are more particularly stumped. I would recommend it if you are looking for something similar.

Groovy doesn’t have the easiest error messages to understand. For example this foxed me for a bit:


links.each {
link -> if(link.startId = anId) { items.add(getItemById(link.endId)) }
}


The error message is:


org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, /Users/rrees/Documents/dev/groovy/MindField.groovy: 37: expecting ')', found '=' @ line 37, column 28.
link -> if(link.startId = anId) { items.add(getItemById(link.endId)) }


However the error is that I am trying to assign a value in an illegal location. It’s that old classic of = versus ==.

When an error blows up the stack trace is huge and this can be extremely distracting when, for example, a unit test assertion is failing. Since I am on the command line at the moment this is unavoidable but it also happens on the console and rapidly you need to clear the console before the next run. I think the console should definitely collapse the stack trace so you see the Message of the exception and then expand the stack trace when you want to see it. Often the Assertion Message is all you need.

Talking of unit tests, I needed them more than normal because while Groovy is very similar to Java there are enough differences to make it important that you double-check your assumptions. Not using equals once was a bit weird for example. Also Groovy arrays seem to differ from the Collections API safe-zone. GArrays are like Lists but don’t seem to support the List interface, no isEmpty for example. list.get(0) doesn’t get you the first element, list.getAt(0) or just list[0] does. Most collection interaction seems to be modelled after Ruby in that you have to get with the closures to do stuff. For some reason I found it difficult to get what I wanted out of the closures in one pass and I tended to get something working with the unit test and then shorten the closure to something concise.

Ruby closures did not seem this hard but maybe it was because the whole language is new on me. As Groovy allows you to bring over the Java idioms you are used to perhaps there was impedance between something that felt familiar but actually required a different approach.

My closing experience was another positive, Groovy’s XML and Swing Builder objects felt incredibly powerful and easy to use. The syntax is tough to grasp but being able to play around with it in the console helped. Swing Builder in particular feels like it could be the way you should make all Java Swing apps.

Overall it is a pretty positive experience. In term of the competitors it felt much more familiar than JRuby but the result was not as neat as Jython scripts tend to feel.