#jdk7

In addition to including the right version of the jar you need to configure Gradle's GroovyCompile task like this:

tasks.withType(GroovyCompile) { groovyOptions.optimizationOptions.indy = true }

If you want to check the code is being compiled correctly the easiest way I've found to do so is to use javap to read the bytecode form a class file and see if there are any invokedynamic instructions. Here's an example:

javap -v -cp build/classes/test co.freeside.jdbi.time.LocalDateSpec | grep invokedynamic

If the class is compiled with the indy option set you'll see some output. Here's what I get from that class:

3: invokedynamic #46, 0 // InvokeDynamic #0:init:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object; 8: invokedynamic #52, 0 // InvokeDynamic #1:cast:(Ljava/lang/Object;)Lorg/skife/jdbi/v2/tweak/ResultSetMapper; 2: invokedynamic #62, 0 // InvokeDynamic #2:getProperty:(Ljava/lang/Class;)Ljava/lang/Object; 7: invokedynamic #52, 0 // InvokeDynamic #1:cast:(Ljava/lang/Object;)Lorg/skife/jdbi/v2/tweak/ResultSetMapper; 3: invokedynamic #70, 0 // InvokeDynamic #3:getProperty:(Lco/freeside/jdbi/time/LocalDateSpec;)Ljava/lang/Object; 8: invokedynamic #76, 0 // InvokeDynamic #4:invoke:(Ljava/lang/Class;Ljava/lang/Object;)Ljava/lang/Object; 13: invokedynamic #79, 0 // InvokeDynamic #1:cast:(Ljava/lang/Object;)Ljava/time/LocalDate; 32: invokedynamic #95, 0 // InvokeDynamic #1:cast:(Lgroovy/lang/GString;)Ljava/lang/String; 35: invokedynamic #95, 0 // InvokeDynamic #1:cast:(Lgroovy/lang/GString;)Ljava/lang/String; 32: invokedynamic #95, 0 // InvokeDynamic #1:cast:(Lgroovy/lang/GString;)Ljava/lang/String;

Of course, bear in mind that not all classes will contain any invokedynamic instructions. If you've used @CompileStatic for example method calls are not dispatched dynamically.

You can include that in a Gradle project by specifying a dependency like this:

compile "org.codehaus.groovy:groovy-all:2.3.3:indy"

However if you have other libraries that depend on groovy they may pull in the regular version transitively giving you two versions of Groovy in your dependency graph. This happens to me a lot with Spock which depends on groovy-all:2.0.5. For example I probably have a dependency like this as well:

testCompile "org.spockframework:spock-core:0.7-groovy-2.0"

I noticed that the External Libraries section of the project tree in IntelliJ IDEA contained two groovy-all jars. One is groovy-all-2.3.3 and the other is groovy-all-2.3.3-indy. That's not good. I only want the indy version.

To debug where the dependency is coming from you can use Gradle's dependencyInsight target like this:

gradle dependencyInsight --dependency groovy-all

By default the dependencyInsight only searches the compile configuration and you may well see nothing there. You can search other configurations by adding an argument on the command line. For example:

gradle dependencyInsight --dependency groovy-all --configuration testCompile

The output from the command looks like this:

:dependencyInsight org.codehaus.groovy:groovy-all:2.3.3 (conflict resolution) \--- compile org.codehaus.groovy:groovy-all:2.0.5 -> 2.3.3 \--- org.spockframework:spock-core:0.7-groovy-2.0 \--- testCompile

Here we can see groovy-all version 2.3.3 explicitly included as a compile dependency and pulled in transitively by Spock. Gradle's conflict resolution has selected version 2.3.3 but what the output doesn't show us is the variant. It doesn't appear to be possible to tell whether the indy or regular flavor of groovy-all is pulled in.

To fix this I first tried forcing the version with:

configurations.all { resolutionStrategy { force "org.codehaus.groovy:groovy-all:2.3.3:indy" } }

The dependencyInsight output changed a little:

:dependencyInsight org.codehaus.groovy:groovy-all:2.3.3 (forced) \--- compile org.codehaus.groovy:groovy-all:2.0.5 -> 2.3.3 \--- org.spockframework:spock-core:0.7-groovy-2.0 \--- testCompile

However, I could still see both versions of groovy-all in IDEA's project tree. It looks like the force resolution strategy doesn't take into account the variant you request.

Unfortunately the only way to get evict the regular groovy-all jar from the dependency tree seems to be to explicitly exclude it from every dependency that pulls it in transitively. For example:

testCompile("org.spockframework:spock-core:0.7-groovy-2.0") { exclude module: "groovy-all" }