This summer, John Rose made a series of posts that Charles Nutter described as "some exciting articles about the future of the JVM and a number of changes potentially for the next Java version." Although John does occasionally touch on the impact to the Java language, the emphasis here is clearly on the VM, and many of these could be seen as important for supporting other languages on the JVM, including both functional and dynamic languages.
In the first of these posts, John Rose described longjumps, or non-local exits that may be necessary for some kinds of closures within the Java language. By using exception-handling mechanics with pre-allocated (e.g. cloned) stack traces, it's possible to get a non-local exit without paying the heavy price of exceptions for flow control. Done well, this can be less than three times the cost of a local exit/return and can be optimized to a machine-level goto instruction. This is particularly performant with a build of Java 7 that optimizes the cost of Object.clone().
Next, John tackles tail calls in the JVM: the ability to compress tail recursion in an explicit, guaranteed fashion ('hard tail calls') or as a compiler optimization ('soft tail calls'). This post evoked a lively discussion in the comments about approaches and uses, but tail calls would likely be of help to functional languages — or languages with some functional-language features — on the JVM, as well as dynamic languages that would benefit from invokedynamic (JSR-292):
It would apply to invokedynamic along with the others. Having hard tailcall would give you more options for implementing dynamic calls: You could branch to a dispatch routine, which would then tailcall the normal routine. (In fact, that's how java.lang.reflect.Method.invoke could work today, at least if return values are not to be boxed.) Since Scheme is a dynamic language, tailcalls are loosely related to JSR 292.
Finally, he looks at Tuples, raising a proposal that dates from 2004 and which describes both 'pure' tuple types (plain tuples) value classes with tuple semantics, which do not need to retain identity (tagged tuples). This can also encompass support for methods with multiple return values. Again, the emphasis on the JVM rather than the Java language is clear here:
It is likely that the tuple-enhanced language will provide a canonical translation between groups of typed values and references to heap objects carrying those values. For example, each value class is likely to support a constructor whose argument signature is the tagged tuple for that class. A tuple is likely to be representable on the heap as a fixed-length Object array or as a generic immutable utility class, with primitive component values in wrapper classes (as in varargs).
And again, in the lively comment thread:
Actually integrating value-like types into Java raises difficult design issues, as you point out clearly. My purpose for this post is to indicate that adding tuples to the JVM is fairly simple, and does not require solution of the language design problems.
Do these proposals strike a chord with you? Are you more interested in seeing the JVM increase support for different languages, or the evolution of the Java language, or are these non-conflicting goals? We'll try and keep you informed on all these topics at InfoQ.