Whither JSR 292?
As of March I'm the chair of JSR 292. Judging by individual contributions and comments I've received, the committee is eager to start digging into details. But we have not yet done so in a coordinated way. Part of the problem is problems with the JCP website, and part is me having to shovel other stuff off of my plate at Sun.
The committee is rather small, and composed largely of dynamic language implementors familiar with the JVM. I really like this setup. I expect we'll be able to validate most of our decisions experimentally, on a "prototype as you go" basis.
The most likely work this calendar year includes a specification and prototype for a first version of invokedynamic, and a demonstration of the benefits for a few major dynamic languages.
If all goes well, the invokedynamic instruction will provide a fast path for common method invocation patterns in several languages. It will be low-level enough to be optimizable by the JVM JIT, yet have enough hooks to support required dynamic features like dynamic typing and method replacement. These hooks are not really new to the JVM, since it's already the case that Java dynamically types calls based on receivers, and can deoptimize calls in response to class hierarchy changes. But the dynamism will no longer be restricted to the Java language and class system.
The basic theme (as I see it) is to unleash the JVM's existing compilation and optimization capabilities, on behalf of dynamic languages other than Java. It seems to me (as a longtime Hotspot JVM implementor) that you can go a long way beyond with the existing bag of tricks, which (at least for Hotspot) includes type profiling, semi-static analysis, lazy compilation, inline caches, splitting between fast paths and slow paths, and (when the real world disappoints the compiler) deoptimization.
Less likely work includes new JVM support for autonomous methods and/or method handles, which are currently simulated by inner classes. and/or reflection. If the current simulations scale well and are sufficiently optimizable, we won't need to tackle this.
Even less likely, but still on the table in case prototyping forces us to consider them, would be additional features for supporting languages. These might include runtime support for language-specific deoptimization, a JVM type other than java/lang/Object which means "dynamic", type profiling hooks, JVM class or object surgery, or relaxation of JVM limits on identifier spellings.
In many dynamic languages, you can add or change methods on classes, or change the class of an object, or (as in Self) add a method to a single object. This is very cool and powerful. It is probably unrealistic to add this flexibility to the JVM's idea of objects and classes. (Some debugger hooks allow such things, but they usually require optimizations to disabled.) I expect that languages which require these features will be able to simulate this flexibility (as they do on non-virtual CPUs) by building their own metaclass structures to keep track of things, and adding lightweight guards to call sites as needed.
I hope there will be open-source work on common runtime facilities on the JVM for dynamic languages. We can put our best tricks into it, and make sure it works well with all features of the JVM, both old and new. But runtime support APIs will not be part of JSR 292, except for the bits which absolutely cannot be disentangled from the JVM itself. The only example of this I can think of now is a query which says whether the JVM version supports JSR 292.