I've just released the first version 1.0.1 (1.0 is compiled for 1.6 only) of the JSR292 backport. So you can now test invokedynamic and method handle invocations without using the latest patch queue from mlvm repository and some wizard's black magic.

The primary usage of the backport is for dynamic language runtime developers (JRuby, Jython, Groovy, etc), they can now use JSR292 API to improve their perf without having to maintain different codebases.
Even if I have no proof, I strongly believe that the JSR2 proposed design will improve performance of JVM languages runtimes.

The backport (at least currently) is a Java agent which modify (instrument) bytecodes at runtime to provide JSR 292 API support on jdk11.5/1.6 VM.
The backport embodies a kind of JIT, i.e the backport agent is able to detect hot call sites and recompile this call sites to a better bytecode blob at runtime.

Comparing to current state of JDK7, the backport run at the same speed or faster than JDK7 depending on the benchmark used. The twist is that currently the JDK7 doesn't provide a full JIT support, that's why the backport is faster :)
This assertion will change soon because I know that the JIT support is around the corner.

Anyway, the JSR292 API provides you an infrastructure that is known to be good in order to be optimized by the VM. So If you are a language runtime developer, I think it worth a glimpse.

How to get JSR292 backport ?

The JSR292 backport is hosted by the JVM language runtime project on Google Code:

  http://code.google.com/p/jvm-language-runtime/.

How to use it ?

You have an example in directory, examples.
The javadoc of JSR 292 is available here (the one included with jdk7 is a bit outdated).
To compile it with latest JDK7 javac
and run it with your favorite VM.

[examples]$ /usr/jdk/jdk1.7.0/bin/javac -Xbootclasspath/p:../mock/jsr292-mock.jar -source 1.7 FidgetDemo.java 
[examples]$ java -javaagent:../lib/jsr292-backport.jar FidgetDemo
Fidgety self-modifying call site...
--- loop #0
[link] new call site: CallSite#970110[fidget(java.lang.String)java.lang.String => null]
[link] set target to Guard:invoke(class java.lang.String itch[class java.lang.String])
fred can't get comfortable
buster can't get comfortable
ricky can't get comfortable
--- loop #1
[link] set target to Guard:invoke(class java.lang.String fuss[class java.lang.String])
fred can't get comfortable
buster is feeling moody
ricky is feeling moody
--- loop #2
fred is feeling moody
[link] set target to Guard:invoke(class java.lang.String bore[class java.lang.String])
buster is feeling moody
ricky needs a change of scenery
--- loop #3
fred needs a change of scenery
buster needs a change of scenery
[link] set target to Guard:invoke(class java.lang.String itch[class java.lang.String])
ricky needs a change of scenery
--- loop #4
fred can't get comfortable
buster can't get comfortable
ricky can't get comfortable
--- loop #5
[link] set target to Guard:invoke(class java.lang.String fuss[class java.lang.String])
fred can't get comfortable
buster is feeling moody
ricky is feeling moody

If you want more examples, JSR292 Cookbook is your friend.
If you want more info about the JSR292 backport, known bugs (none) or limitations (some), you can read the README.txt.

invokedynamically yours,
Rémi