PROPOSAL: language support for JSR 292

[John Rose]

On May 1, 2009, at 2:16 AM, Howard Lovatt wrote:

> Great work on the proposal.
Thanks.

> There appears to be four controversial points about the proposal:
>
> 1. The use of Void as a bottom type; this seems most natural to me and
> I would like to see this throughout Java (in fact I have suggested
> this before on I think Alex Buckley's blog).

I really don't want to get into the middle of the Void vs. Null  
debate; I just want one to win so I can use it! :-)

> 2. Making InvokeDynamic a normal uninstantiatable type (like
> Collections); again this seems fine to me, no need for the compiler to
> issue a warning it doesn't for T extends Collections and that isn't a
> problem

I think that's settling down.  Some leftovers from the Dynamic type  
proposal complicated the discussion (to an extent that surprised me!).

> 3. The use of primatives in angle brackets for return types; if people
> don't like that you could use a cast to indicate return type (like you
> would for a null argument for example when disambiguating overloaded
> methods)

Yes.  There are several ways to do it:  Faux type parameter, target  
typing (via cast or more generally), an extra reified type argument, a  
whole new syntax (the very first prototype used backquote: yech).

Although the faux type parameter impinges on true type parameters (as  
Neal objected), I think it's the least irregular way to express what's  
needed, and one of the more intuitive (to those who already know Java  
generics).

> 4. The throwing of checked exceptions; probably OK, the top level data
> loggers that I have seen have caught Exception or above so I don't
> think this will be a problem in practice

Yes, we're thrashing that one out now.

Good recap; thanks.

> At a higher level, rather than details of the proposal, it would be a
> nice addition to have a convenience interface, lets for the sake of
> argument call it Dynamic, that behaved like a top level class in a
> dynamic language and you implicitly had to define a private static
> missingMethod method in any class that implemented Dynamic.

Interesting.  There are lots of degrees of freedom in integrating  
static Java with dynamic languages.  The present proposal is intended  
to be minimal, but there is lots to dream about here for the future.

> Then a
> class that implemented Dynamic or any class that used an object of
> type Dynamic would be converted automatically be the compiler to use
> InvokeDynamic, e.g. your simple example would become:
<snip>

So Main would inherit the ability to form invokedynamic calls from  
Dynamic.  I think that would make many (not all) Java programmers feel  
very insecure about the meaning of the code in such a scope.

My hope right now is to lay down a good enough foundation to enable us  
to play with such things in Java 7.

-- John