Programming Grails - Cdn.oreilly.com

println hello.getClass().superclass.name
The class itself will have a name like ConsoleScript14$_run_closure1. Nested closures
extend this naming convention; for example, if you look in the classes directory of a
Grails application, you’ll see names like BuildConfig$_run_closure1_closure2.class,
which are the result of having repositories, dependencies, and plugins closures de‐
fined within the top-level grails.project.dependency.resolution closure.
The dollar sign in the class and filename will look familiar if you’ve used anonymous
inner classes before. In fact, that’s how they’re implemented. They’re different from
anonymous inner classes in that they can access nonfinal variables outside of their scope.
This is the “close” part of closure—they enclose their scope, making all of the variables
in the scope the closure is in available inside the closure. This can be emulated by an
inner class by using a final variable with mutable state, although it’s cumbersome. For
example, this Java code doesn’t compile, because i isn’t final, and making it final defeats
the purpose, because it needs to be changed inside the onClick method:
interface Clickable {
void onClick()
}
int i = 0;
Clickable c = new Clickable() {
public void onClick() {
System.out.println("i: " + i);
i++;
}
};
We can fix it with a final 1-element array (because the array values are still mutable):
final int[] i = { 0 };
Clickable c = new Clickable() {
public void onClick() {
System.out.println("i: " + i[0]);
i[0]++;
}
};
but it’s an unnatural coding approach. The Groovy equivalent with a closure is a lot
cleaner:
int i = 0
def c = { ->
println "i: $i"
i++
} as Clickable
So how does Groovy break this JVM rule that anonymous inner classes can’t access
nonfinal variables? It doesn’t—it uses a trick like the one above. Instead of using arrays
like the above example, there’s a holder class, groovy.lang.Reference. Enclosed vari‐
10 | Chapter 1: Introduction to Groovy