Scope ambiguities between outer and super

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]

Posted by jrose [Java] ( August 01, 2007 05:51 PM ) Permalink | Comments[1]

June Language Dynamics

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.

Posted by jrose [Java] ( June 05, 2007 11:48 PM ) Permalink | Comments[0]

Longjumps Considered Inexpensive

...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]

Posted by jrose [Java] ( May 11, 2007 01:27 AM ) Permalink | Comments[3]

JSR 292 Deep Dive Notes

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

Posted by jrose [Java] ( May 09, 2007 05:53 PM ) Permalink | Comments[1]

Whither JSR 292?

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]

Posted by jrose [Java] ( May 07, 2007 01:44 AM ) Permalink | Comments[0]

Autonomous Methods for the JVM

...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]

Posted by jrose [Java] ( January 06, 2007 05:49 PM ) Permalink | Comments[0]

Duck Typing in the JVM

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]

Posted by jrose [Java] ( January 03, 2007 05:50 PM ) Permalink | Comments[0]

Better Closures

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]

Posted by jrose [Java] ( August 31, 2006 06:03 PM ) Permalink | Comments[8]