John Rose @ Sun: John Rose's weblog at Sun Microsystems

In order to work with dynamic types, method handles, and invokedynamic I have made some provisional changes to javac as part of the Da Vinci Machine Project. (There is a full description for Project COIN; it's almost ready for publication, and I'll blog about that when I push it.) It is most desirable, of course, to program invokedynamic call sites as Java expressions, not just ASM code, and that's what those langtools patches are for.[Read More]

A decade ago, I briefly contributed to this topic in an aside in the original whitepaper from Sun:

Sometimes the combination of inheritance and lexical scoping can be confusing. For example, if the class E inherited a field named array from Enumeration, the field would hide the parameter of the same name in the enclosing scope. To prevent ambiguity in such cases, Java 1.1 allows inherited names to hide ones defined in enclosing block or class scopes, but prohibits them from being used without explicit qualification.

This rule has been dubbed the "Mother May I" rule...[Read More]

Charles Nutter has started an interesting Google Group which is worth the attention of language wonks:
  http://groups.google.com/group/jvm-languages

I recently spent a pleasant hour thinking about Common Lisp on the JVM; see this thread:
  http://groups.google.com/group/jvm-languages (Kicking off: Jatha)

Meanwhile, the JSR 292 Expert Group will be working this summer on a simplified POC (proof of concept) that can serve as the basis for coordinated experiments in JVM and language implementation.

I expect that when we have something that passes the red-face test, we will be soliciting comments and experiments, based on open source bases. This is not the Final Answer, but simply the Initial Answer.

...You can pre-allocate an exception and use it as many times as you want.... With current server VM optimizations of this technique, the cost of a non-local return is less than three times the cost of a plain (local) return; with the client VM the ratio is ten. See the code example and benchmark for details: NonLocalExit.java (javadoc).

...Languages on the JVM (including Java, if that’s the direction it goes) can implement non-local returns reasonably directly, and the JITs will turn them into local jumps in important common cases.

[Read More]

We had a productive pick-up meeting at JavaOne. Here are my minutes.[Read More]

As of March I'm the chair of JSR 292.... 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....

[Read More]

...Because the JVM is a highly successful investment in efficient and robust support for byte-coded methods, it is worth while looking at teasing apart JVM methods from JVM classes. If this can be done well, the strengths of the JVM can be applied to programming tasks (scripting, functional programming) beyond the current scope of Java.

So, here is a design sketch for autonomous methods (AM) in the JVM. It is not complete, but should be suggestive of new ways to support languages beyond Java....

[Read More]

There's a thought-provoking post about invokedynamic and duck typing here: http://headius.blogspot.com/2007/01/invokedynamic-actually-useful.html

Charles asks, "Would all methods accept Object and return Object? Is that useful?"

[Read More]

As I mentioned earlier, a closure per se has a special nature which it does not share with other kinds of functions. A closure is produced from snippet of code, written in the midst of a larger block of code, in such a way that the meaning of names within the snippet are consistent with the enclosing block.

Let‘s continue to examine the case for (a) better closures and (b) slightly better type parameters but not (c) function types, with the most enjoyable part, (a).[Read More]

Java needs (a) better closures and (b) slightly better type parameters but not (c) function types. Let's examine the last first...[Read More]