A bit of help with closures in Groovy

Beginning closures

The first thing to do is to read the guide to closures in Groovy’s documentation. If you can read it all the way from top to bottom in one sitting without your head hurting, you’re doing it wrong. What you should find is that you reach something like:

and your mind starts frantically trying to build parsers and execute the code until the assert passes. All you need to know, however, is that f is being defined as something like a traditional function, one which takes two values called list and value as parameters. The -> separates the parameter names from the definition of what should be done with those internal variables, in this case the value variable is appended (<<) to the list variable. The updating of the list is actually updating x each time, which is why x has changed by the time the assert is executed.

Once you’ve got your head around that, you should be able to get up to this bit in the documentation:

You might start to wonder where the m comes from and worry that i and j aren’t defined, but don’t worry, it does all make sense. What is happening is, the arguments to f are not just a simple tuple this time, they have the form of a map, which is given the name m in the definition of f. This means that when x is defined as a key in the map, m.x is a way of referencing the value of this key. The same is possible for m.y, and the unbound variables are given the names i and j, also in the definition of f. When all these variables are added up, they of course come to 20, so there is no funny multiplication or decimal numbers involved.

Silent fail

I did mention in my earlier post that it was difficult getting Swing to do what you wanted in Groovy. A good example of how opaque the technology can be is to look at the documentation page for lineBorder. While the page does include a section of examples at the end (which not all the pages do), it contains 3 seemingly contradictory examples for how to use lineBorder, one as the value in a map, one as the content of a closure, and one as what looks like a function call. It’s certainly not clear when you are supposed to use any of these, so you just have to hope that Groovy will inform you if you choose the wrong one, which is not always the case.

Take for example the challenge of trying to set the appearance of your program’s graphical interface. Not only does Groovy assign defaults for you, like a grey background, but it then ignores things you specify like background: Color.GREEN (which you have to try specifying in at least 3 different places) and does not even produce an error or warning telling you why your code is being ignored. Similarly you can try specifying vgap: 0 to adjust the spacing, but the best you can manage is to adjust the spacing of some completely irrelevant part of your interface.

The worst example, though, is when this conspiracy of silence overlaps with Groovy trying to be too clever. I present two lines of code which should almost be a test case for checking whether a language or execution environment is designed to help the programmer:

If you thought that either of those lines would produce the output “3” then you have a lot of exciting discoveries to look forward to when you start using Groovy. Also, if you thought that the two lines would produce the same output, then you might want to spend some time multiplying matrices until this non-commutativity becomes intuitive. Finally, if you thought that the first line would produce “111” and the second line would produce an error message you are half right, because the second line, instead of doing something useful, does nothing at all, not even give you an error message to tell you you’ve made a mistake.

Bug

I could try running this code in the latest version of the groovyConsole to check that this behaviour is still present, but after the last upgrade I did I now get this error message when I try to load it: foo@bar$ groovyConsole java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108) at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130) Caused by: java.lang.UnsatisfiedLinkError: Can’t load library: /usr/lib/jvm/java-6-openjdk/jre/lib/ext/libjava-access-bridge-jni.so at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1666) at java.lang.Runtime.load0(Runtime.java:787) at java.lang.System.load(System.java:1022) at org.GNOME.Accessibility.JavaBridge.(JavaBridge.java:352) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at java.lang.Class.newInstance0(Class.java:372) at java.lang.Class.newInstance(Class.java:325) at java.awt.Toolkit.loadAssistiveTechnologies(Toolkit.java:786) at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:874) at javax.swing.UIManager.getSystemLookAndFeelClassName(UIManager.java:617) at javax.swing.UIManager$getSystemLookAndFeelClassName.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:121) at groovy.ui.Console.main(Console.groovy:148) … 6 more This is even if I install libaccess-bridge-java-jni. Of course, if I try to run groovyConsole through a graphical menu, then I don’t even get this error message. Perhaps I just have to wait for version 6b16-2, but until then there’ll be no more Groovy programming for me.

Does this mean I should be using Scala instead?