Foreword

Since Groovy 2.0, we added support for the JVM invokedynamic instruction. This instruction is supported since Java 7 and is a new bytecode instruction in the JVM that allows easier implementation of dynamic languages. This instruction will also be used internally, by the JVM, for the upcoming lamdba support in Java 8.

This means that unlike APIs, AST transformations or syntactic sugar, this feature is not visible to the developer or the end user. It is a compilation and runtime feature only. This means that given two programs written in Groovy, you have the choice to compile it with or without invokedynamic support. Whatever you choose, it comes with pros and cons:

The distributions

Two jars

The Groovy distribution comes with two jars:

The first jar is Groovy compiled without invokedynamic support, while the second one has invokedynamic support bundled. As Groovy core and the groovy modules are sometimes written in Groovy, we currently have no choice but issuing two distinct versions of Groovy. This means that if you pick the "normal" jar, the groovy classes of groovy itself are compiled with call site caching (1.5+), while if you use the "indy" jar, the groovy classes of groovy itself are compiled using invokedynamic. This means that the invokedynamic version of Groovy doesn't make use of the old call site caching mechanism.

Both jars contain a fully working groovy implementation. They are mutually exclusive (don't put both on classpath).

Command-line and indy

If you download the distribution and that you use the command line, it's always the "normal" version of Groovy which is picked up in classpath. This means that whatever command you use (groovy, groovyc, groovysh or groovyConsole), invokedynamic support is not available out of the box. To use the invokedynamic version, you have to switch the jars manually. The distribution makes use of the jars in the lib directory, while the indy jars are available in the indy directory. You have three things to do:

Here's a bash script that would do it all at once:
$ for f in `ls lib/groovy*.jar | cut -d/ -f2`;do k=`basename $f .jar`; mv lib/$k.jar lib/$k.jar.old; cp indy/$k-indy.jar lib/$k.jar ; done

Running groovy script from command line

The usual way to run a script from the command line is by "groovy foo.groovy", where foo.groovy is the groovy program in source form. To use indy for this you have to use the indy distribution and "groovy --indy foo.groovy". Doing this without the indy distribution will result in an error message.

The compilation flag

Independently of the jar version that you use (and after having exchanged the jars as described), invokedynamic support requires a specific compilation flag (indy). If you want to compile your classes with invokedynamic support, this flag must be set at compile time. The following tables show you what happens with user compiled classes and groovy core classes depending on the jar you use and the compilation flag:

indy flag

offon
normal jarcall site cachingN/A
indy jarcall site cachinginvokedynamic

user compiled classes

 

indy flag

offon
normal jarcall site cachingN/A
indy jarinvokedynamicinvokedynamic

core groovy classes

So even if you use the indy jar, if you don't use the invokedynamic flag at compile time, then the compiled classes will use the "old" format, meaning they will use the JDK1.5+ classes without invokedynamic.