Groovy 2009 Year in Review and 2010 Predictions

Groovy in 2009

Groovy 1.6 Released
Groovy 1.6 was released at the beginning of the year, and the most exciting new features have turned out to be Grape and AST Transformations.

Grape allows a developer to declare dependencies within their Groovy source code and then, at runtime, Groovy will download and install the dependencies using Ivy repositories. Want to ship scripts to your operations team? You no longer need to email or build JARs! It's no Jigsaw, but maybe that's a good thing.

AST Transformations allow developers to hook into the Groovy compiler and alter the way the code is compiled. This has enabled great work like the @Bindable and @Delegate annotations, as well as many forward thinking (read: visionary) libraries like the Spock testing framework and the CodeNarc static code analysis tools. Watch for more cool libraries and frameworks to use these features in 2010.

Griffon Released
While Flex and JavaFX duked it out for developer mindshare in the coveted (and hyped) RIA space, a groovier team quietly forked the Grails codebase and adapted it for Swing desktop applications. Griffon is way more than a dynamically typed builder pattern on top of Swing components. Griffon gives you property binding to widgets (you're not the only one Flex), a standard and simple MVC architecture without a spaghetti monster diagram (that's you PureMVC), more components than just a TextBox (the complete JavaFX widget set last Winter), a plugin system that allows you to decompose problems into reusable addons, and an easy way to deploy your app via webstart. If the Griffon team can keep the energy they had in 2009 then 2010 should be the year of the lion. Or eagle... or dog. What the hell is a griffon anyway?

Groovy Tooling Explosion
Looks like IntelliJ IDEA has some competition for best Groovy IDE. The Groovy Eclipse plugin got new life as Andrew Eisenberg revived the project, and SpringSource released better Grails support in SpringSource Tool Suite. Was the open sourcing of IDEA a response to the new competition? Who cares, it's free now! While IDEA is still the best IDE for Groovy, Groovy users will surely benefit from each IDE maker trying to outdo the other.

VMWare Buys SpringSource
Seriously, who saw this coming? This week at Groovy/Grails Exchange, Graeme Rocher demoed deploying to the cloud from his IDE (according to Twitter). Easy cloud deployment is good news... it will end the monthly "who do you use for Java hosting?" questions on user groups. Now if only the price would come down.

GR8 Conference
A Groovy conference created by the community, for the community, and priced for the community. It's great to see not for profit additions to the Groovy conference scene, and next year sees two GR8 events: one in Europe and one in North America (Minneapolis!). In other community news, Chicago Groovy Users Group started posting video sessions to blip.tv. Can we get some other GUGs to do the same?

A Groovy 2010

Don't think of these as predictions... think of them more as premature facts.

Gradle
To be clear: Gradle is not a Groovy technology. It is an enterprise build system written in Java with Groovy used as a build script. Anyway, the 0.9 release will include "Smart Execution/Incremental Compile" and 1.0 will support multi-threaded builds. These are enterprise level features that would be totally unique to Gradle... and they're sure to intice a lot of unhappy Maven developers. If the Gradle team can hit 1.0 and publish a book(!), then a lot of people will migrate.

GPars
I can't find anyone with anything bad to say about either the Fork/Join Framework or BMW Motorcycles... and I just sold my bike to spend more time coding. GParallelizer hasn't been widely adopted to date, in my opinion because it chased the Actor-Model hype a little too strongly. But now it's been rebranded GPars and an all-star team has been assembled to work on it. This isn't a good project to just follow, it's a good project to download and play with. Get the bits and join the mailing list. Your opinion counts! It's too bad that they hate cool the logo I made for them.

Griffon
The decision by the Grails team to make almost everything a plugin was genius. It provides a standard mechanism for everyone to modularize their own applications, and provides an easy path for users to push their non-business-critical plugins back into the community. If Griffon users embrace the plugin system, and then push their plugins back to the community, then Griffon could be a real alternative to JavaFX/Flex by the end of the year.

Java Closures
I wish the JDK team the best of luck meeting their September 2010 release deadline. While I have doubts that JDK 7 will ship in 2010, I do believe the closure syntax will be decided upon. And Groovy will be the first Java language to support that syntax. Whether a version of Groovy containing Java closures actually ships before JDK 7 is probably dependent on how the Groovy team wants to address the modularization issues of Jigsaw, which sounds like a much harder problem to solve.

Groovy IDE Support Improves... a little
IntelliJ IDEA still leads in features by a wide margin, but Eclipse and STS aren't stealing IDEA users, they're stealing TextMate users. People just want to debug without parsing all the files in the world. IDEA will remain the sole provider of Groovy refactorings, intentions, and auto-completions. But Eclipse will finally become a better alternative than a text editor. However, the open sourceing of IDEA should make it easier (and faster) to get IDEA support for newer frameworks, which is a good thing.

Groovy-User Mailing List Shuts Down
For the entire month of June, all posts to groovy-user will be answered with the same response: "This is covered in Groovy in Action 2nd Edition". By the end of the month admins will simply replace the mailing list home page with an advertisement for the book.

What Won't Happen

InvokeDynamic
InvokeDynamic is set to greatly improve implementing and running dynamic languages on the JVM. Only it won't be released until September 2010 at the earliest. Sure you can get the OpenJDK now, but most users won't do that. I predict InvokeDynamic being the story of 2011, not 2010... and even then I bet the JRuby guys beat us to it.

The Java Store
Let me get this straight... you want me to pay US$50 yearly so that I can give my Griffon app away free on the Java Store? You gotta be kidding. Griffon + the Java Store could be a match made in heaven: Griffon makes JNLP Webstart simple to configure and the Java Store handles hosting the files. But Sun/Oracle is turning too many hobbiest and small time developers away with their entrance fee. Are you listening Mr Ellison? I said I want... oh wait, you're not listening. How hard would it be to make the Groovy Store?

This was fun. What are your Groovy 2009 highlights and 2010 predictions?

Simple XML Testing from Java

2009 is coming to a close and I'm writing a blog post about Java and XML. The blog's called "behind the times" for a reason: no fancy dynamic languages, JSON, or REST. Straight up XML on Java action.

One of my favorite editions to our enterprise toolset this year was XMLUnit. We'd been using Groovy in testing, and multi-line strings led to a ton of expressiveness in test cases... but then we stopped using Groovy. I switched back to Java testing and was left with making String based assertions and doing String#contains() calls. Not ideal; enter XMLUnit.

XMLUnit supports XML based equality comparisons so that things like these two snippets are equal:

<root/>

<root></root>

As well as these:

<root>data</root>

<root>
    data
</root>

In fact, there's a whole gaggle of options around what is a meaningful versus a meaningless difference. For instance, I often consider two dates equal as long as they are formatted correctly (ignoring those pesky timestamp issue is nice).

The problem with XMLUnit is that the API is not as nice for the simple case as it could be. What I want is a simple custom assertion that asserts two XML snippets as similar. Something like this:

XmlAssertions.assertXmlSimilar("<root/>", "<root></root>"); 
XmlAssertions.assertXmlSimilar("<root>data</root>", "<root>\ndata\n</root>\n"); 

This was as simple as creating a small utility class and hiding the XMLUnit API behind a nicer custom assertion:

import java.util.List;
import junit.framework.*; 
import org.custommonkey.xmlunit.*;

public class XmlAssertions {

    private static final String ERROR_MSG = "XML comparison failure. \nExpected: %s\nReceived: %s\n%s"; 

    static {
         XMLUnit.setIgnoreWhitespace(true);
    }

    public static void assertXmlSimilar(String expected, String actual) {
        try {
            Diff diff = new Diff(expected, actual);
            List differences = new DetailedDiff(diff).getAllDifferences();
            Assert.assertTrue(
                String.format(ERROR_MSG, expected, actual, differences), 
                diff.similar());
        } catch (Exception ex) {
             Assert.fail(String.format(ERROR_MSG, expected, actual, ex.getMessage())); 
        }
    }
}

The raw XMLUnit code is clearly not something you want to see within the body of a test method. The custom assertion seems simple, but it's made a real pleasure of writing XML based functional tests around all our web services. Feel free to steal my code here: http://svn.assembla.com/svn/SampleCode/xmlunit/XmlAssertions.java

The True and False of Groovy's AST Builder

Last week saw three(!) conference sessions on Groovy AST Transformations. At SpringOne2gx I started with an AST Transform deep dive, Venkat followed up with a more gentle, and better performed, overview of Transforms, and I finished out with a video taped AST talk at StrangeLoop (watch infoQ for the video).

At the sessions there was some confusion about the API of the new AstBuilder in Groovy 1.7 (currently in RC1). Hopefully this post can clear that up.

The AstBuilder helps you create abstract syntax trees, and the User Guide is the best place to start learning about it. It lets you create the AST for code by simply passing the code into a method:

List<ASTNode> x = new AstBuilder().buildFromCode { " a constant " }

The big question everyone has is, "What's in the List of ASTNodes?"

The question is mostly easily answered by looking at GroovyConsole's AST Browser. Just type in "a constant" into GroovyConsole and press Ctrl+T/Cmd+T to view the AST:


Do you see that there are two root nodes? A BlockStatement and a ClassNode? The reason for this is that all Groovy scripts are compiled into classes of type Script by the compiler. Remember, to the JVM there are no scripts, only classes. If you expand out the AST, you can see that the script (in this case, the ConstantExpression) is in two places in the AST: within the BlockStatement and within the Script#run method:


So this is why the AstBuilder returns a List of ASTNodes. You'll be returned both the script BlockStatement and the Script ClassNode. For the most part, you're probably only interested in the script and not the ClassNode. The boolean parameter on the buildFromCode and buildFromString methods exist so that you don't have to see that ClassNode. The default value of this 'statementsOnly' parameter is true, so be default you'll only be given the script BlockStatements.

List<ASTNode> x = new AstBuilder().buildFromCode { " a constant " }

assert x[0].class == BlockStatement
assert x[1] == null

But when you need it, you can specify 'false', meaning you want the ClassNode as well as the BlockNode:

List<ASTNode> x = new AstBuilder().buildFromCode(
       CompilePhase.CONVERSION,
       false,  // get the ClassNode
       { " a constant " })

assert x[0].class == BlockStatement
assert x[1].class == ClassNode

For a fun, educational exercise, create multiple classes in GroovyConsole and see what the AST looks like. Hopefully you won't be surprised. But please don't enter an anonymous class because then you'll break the AST Browser! (It's a defect in 1.7 RC1 that I promise to fix soon).

Enjoy!

Y-Combinator in Groovy

File under uselessly cool (for now at least).

A Y-Combinator in Groovy!

def Y = { le -> ({ f -> f(f) })({ f -> le { x -> f(f)(x) } }) }

Update: @mrdillon was kind enough to point out that my original Y used recursion. His revision is better.

And to prove it works, you can define a recursive factorial function without using recursion in the language.

def factorial = Y { fac ->
    { n -> n <= 2 ? n : n * fac(n - 1) }
}

assert 2432902008176640000 == factorial(20G)

The one-liner closure in the middle is the meat of the method definition and is a classic (i.e. horribly inefficient, known deficient) factorial implementation. I wouldn't write code this way but it makes a nice terse example when written in one line.

So is this useless? Not at all! But getting to an explanation of its use requires just a few examples.

Consider a recursive function that determines if an element is a member of a list. I guess you should also consider that List#contains(Object) does not exist. Here is a first draft of such function:

def isMember(element, list) {
    if (!list) false
    else
        if (list.head() == element) true
        else isMember(element, list.tail())
}

assert isMember(2, [1, 2, 3])

Let's just step through it briefly.

if (!list) false
... a simple terminating condition, an empty list never contains the element

if (list.head() == element) true
...if the first item in the list is the element then yes, we found it!

else isMember(element, list.tail())
....otherwise, check all the other items in the list for the same condition

Over time, the isMember will be recursively applied to each element in the list, and call stacks will build up in memory until the element is found, the list is fully checked, or you run out of stack space.

The problem with isMember is the redundancy. Notice how 'element' is always passed as a parameter? The value never changes over the life of the function application, so we shouldn't bother passing it every time. We have closures, so why don't we just 'close over' the value of element and remove the redundant data passing?

We can do it, but because of Groovy's limited recursion support, the implementation is kinda ugly. What I'd like to do is create a recursive closure that captures element once, but Groovy forces me into declaring an inner looping function on one line and defining it on another:

def isMember(element, list) {
    def inner
    inner = { lat ->
        if (!lat) false
        else
            if (lat.head() == element) true
            else inner(lat.tail())
    }
    inner(list)
}

assert isMember(2, [1, 2, 3])

This is where Y comes into play. I want a recursive closure and that is what Y does! Check out how Y allows me to define a recursive function locally within a method. No more split on declaration/definition.

def isMember = { element, list -> {
    def inner = Y { inner ->
        { lat ->
            if (!lat) false
            else
                if (lat.head() == element) true
               else inner(lat.tail())
        }
    }
    inner(list)
}

assert isMember(2, [1, 2, 3])

It's not uselessly cool any more is it? Oh wait, without tail call optimization on the JVM you will surely run out of stack space with a nasty StackOverflowException by writing code like this. So don't do it!

I guess it's pretty useless after all.

And if you're looking for a fun weekend project, why don't you do a different one of the Rosetta Code challenges
that are missing for Groovy: http://rosettacode.org/wiki/Tasks_not_implemented_in_Groovy

Tschüs!