PROPOSAL: language support for JSR 292

[John Rose]

On Apr 29, 2009, at 8:14 PM, Neal Gafter wrote:

> These proposals appears to allow primitives and "void" to be used as  
> generic
> type arguments for this special class.  This use of the syntax has  
> nothing
> to do with generics.  Therefore, I believe it is an abuse of syntax.

It's an extension of the syntax, surely.  Let me try to unpack  
"abusive".

1.  Is it so ugly as to make it hard for programmers to learn?  I  
think not.  And I think the alternatives are more objectionable on  
that score.

2.  It is a bad extension if it interferes with existing or reasonable  
future uses of that syntax.  Will it interfere?  It does not now  
interfere since the JVM knows nothing about generics.

It might interfere if in some future Java world generics were to be  
reified (as in C#), and there were some notation for naming an  
implicit method (from within magic InvokeDynamic) equipped with type  
parameters.  To call such a method, we would need to give type  
arguments, and then we'd be embarrassed, since there is already a faux  
type parameter, the return type.  But, shaking those sorts of future  
scenarios around in my head, I can't come up with one that doesn't  
have a simple workaround, such as retaining InvokeDynamic in its  
limited capacity, and adding another more feature-ful source of  
implicit methods.

3. Is it not self-consistent?  In the current design a dynamic call  
with a type argument appears to the caller as if the referenced  
implicit method is parameterized by one type parameter, the return  
type.  (The JVM sees something different, naturally.)  The ability to  
specify <int>, and also to drop the type argument altogether, may be  
viewed as a sugar that means "the implicit method doesn't have a type  
parameter, instead it has int or Object as a fixed return type".  That  
looks consistent to me.

If in some future world we allow primitives somehow to be type  
arguments, then <int> could stop being sugar, but there would be no  
change of meaning.

Maybe there's some other objection (or meaning to "abusive") that  
still needs to be pointed out?

> If you're going to extend the language to support this special  
> InvokeDynamic
> class, you might as well just define language support for dynamic
> invocations directly without the magic class and generic  
> extensions.  I
> don't think the current spec for Dynamic fits with the current type  
> system.
> If you are adding special types like InvokeDynamic, I think they  
> must be
> reference types (i.e. a subtype of Object).  You should try to get  
> some
> information about what C# has done in this area for "dynamic", as I  
> believe
> it could be applied to Java and result in a clean solution.

The magic class, which really functions as an importable keyword, is  
the simplest way I know to allow the creation of invokedynamic sites.

A dynamic type, as in C#, would be another more useful way to create  
invokedynamic sites, but it would be several orders of magnitude more  
complex, because of its interactions with static typing, expressions,  
and the runtime support.

> By the way, now is a good time to add the boxed "Null" type, which  
> has no
> instances, referring to the type of null.  I don't think this  
> purpose is
> well served by using java.lang.Void.

Thanks for that push.   I hope that is possible, although touching  
java.lang.* is difficult.  I've thrown my lot in with Null; see the  
wiki.

If the planets do not align for the creation of java.lang.Void in JDK  
7, I suppose programmers can decide among themselves to use Void,  
along with an explicit cast, as (Void)null.  If that happens, we'll  
encourage MOP writers to recognize both Void and anything named  
"java.lang.Null" as interchangeable names for the null type.

-- John