PROPOSAL: language support for JSR 292
John.Rose at Sun.COM
Fri May 1 14:46:29 PDT 2009
On Apr 29, 2009, at 8:14 PM, Neal Gafter wrote:
> These proposals appears to allow primitives and "void" to be used as
> type arguments for this special class. This use of the syntax has
> 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
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
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
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
> 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
> 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
> information about what C# has done in this area for "dynamic", as I
> 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
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.
More information about the coin-dev