A Spectacular Collision

Programming multithreaded or concurrent application is not for the faint of heart. It takes a surprisingly long time to get your head around concurrency, and much worse, generally it's very difficult to know whether or not your solution is correct. Fortunately there are people like Doug Lea and Brian Goetz who focus on these issues, build solutions and write books about them.

Their solutions are available to us in the form of the ready-made classes in the Java API package java.util.concurrent. The Groovy Actors framework uses a number of these classes and interfaces to keep a careful eye on how the agents interact in time, so that nothing strange happens. Similar to Enterprise Java Beans, threading issues are the concern of the container.

The key thing to realize is that each Groovy Actor only does one thing at any given time, and if several others communicate with one, they do so in sequence. The actor is the syncrhonization unit.

Feelin' Groovy

These wonderful concurrency tools are available to Java programmers, but there's still this issue of what the code looks like when you are writing large numbers of asynchronous interactions. The nicest way to code these interactions is by using callbacks, where one actor calls a function with a void return value on another and the reply is given later in the callback. Anything is possible in any language, but sometimes the syntax gets out of hand, like in the case of callbacks in Java:

otherPerson.say("Hello", new Callback() {
    public void call(Object answer) {
        System.out.println("They replied "+answer.toString());
    }
});

Compare that to the tidiness of a closure in Groovy and you'll see why it makes sense to code in a language like this when most of what your actors do is chat asynchronously with each other.

otherPerson.say('Hello') {
    println "They replied $it"
}