Suppose you want submit job to ExecutorService.
The Baroque version
You could create a class that implements Callable:
class MyJob implements Callable<Integer>{
    @Override
    Integer call() throws Exception {
        return 42
    }
}
and give it to the executor service:
def 'submit callable as MyJob object'() {
    expect:
    executorService.submit(new MyJob()).get() == 42
}
The response is, as expected, 42.
Map as Callable version
You want to use this job only in one place so why not inline this class:
def 'submit callable as map'() {
    expect:
        executorService.submit([call: { 42 }] as Callable).get() == 42
}
The response is again 42.
Groovy closure version
Why not use closure instead of map?
def 'submit callable as closure'(){
    expect:
        executorService.submit { 42 }.get() == 42
}
The response is … null.
Condition not satisfied:
executorService.submit { 42 }.get() == 42
|               |             |      |
|               |             |      false
|               |             null
|               java.util.concurrent.FutureTask@21de60b4
java.util.concurrent.Executors$FinalizableDelegatedExecutorService@1700915
Why? It is because Groovy treats this closure as Runnable, not Callable and Future#get returns null when task is complete.
Groovy closure version with cast
We have to cast our closure before submiting to executor service:
def 'submit callable as closure with cast'() {
    when:
        int result = executorService.submit({ return 42 } as Callable<Integer>).get()
    then:
        result == 42
}
The response is, as expected, again 42.
What interesting, the same test with inlined result variable fails… Strange… It could be Spock framework error.
Source code is available here.