PROPOSAL: language support for JSR 292
John.Rose at Sun.COM
Mon Mar 30 02:12:23 PDT 2009
On Mar 29, 2009, at 7:55 AM, Josh Suereth wrote:
> I'm curious as to why you chose to not allow catching checked
> exception from
> Dynamic method calls
That's a very good point. In fact, invokedynamic (like any other
invokex) can throw any kind of exception at the JVM level. Since at
the Java level it is untyped and therefore not statically checked, it
must be possible, though not required, to catch checked exceptions.
On Mar 29, 2009, at 12:55 AM, Neal Gafter wrote:
> Could you please send the proposal to this list?
> I don't really understand the intended specification with respect to
> Dynamic. It is one the one hand described as an object type (e.g.
> section 1.9)
Dynamic is a reference type, but not a subtype of Object. This means
it does not have the methods of Object. I don't think I used a phrase
meaning "object type".
> but on the other hand it doesn't inherit from Object
> (section 1.1). You can't have it both ways. I can't tell, for
> example, whether Dynamic is a valid type in a generic type parameter.
I haven't decided yet if the language of the JLS for GTP's should have
special pleading to allow Dynamic to have a type upper bound (and to
erase) to Object, analogous to the special pleading I wrote that
Dynamic is a subtype of Object. The JLS rules as they stand today
make it impossible to have List<Dynamic>.
> If the answer is yes, then it must have Object as a supertype.
Unless the type bound is itself Dynamic; then the JSL rules as written
currently would allow Dynamic itself as a GTP. What they won't allow
(as written) is Dynamic to be the GTP for a type variable bound by
Object (or something else other than Dynamic).
Hmm... If it's useful to have a field or return value or array
element of type Dynamic, it is equally useful to have List<Dynamic>.
So I guess, yes, there needs to be a special pleading, a tweak about
Dynamic and type bounds. The kind of tweak which won't cause a
cascade of further tweaks--I don't know yet if that is possible. Can
you give me a reference to what C# does about dynamic vs. type bounds?
I suppose we could declare that Dynamic *does* have Object as a super
class, but somehow hides all the inherited methods, even the ones that
are final. That would be a different tack. That would require some
special pleading in rules for method resolution; maybe that would be
Regardless of the specification details, the overall goal is to make
Dynamic into a type which has even less static content than Object,
but allows any method call to be switched through invokedynamic.
> might find it useful to review what C# has done in this area with
> their type "dynamic".
Yes, while working on this proposal I just saw Jim Hugunin present at
PyCon; he gave a brief introduction to dynamic in C# 4.0. For my
part, it was another funny case of parallel evolution between C# and
Java. Not so funny for us, actually, that C# is releasing while Java
is just cogitating. Snail-like pace is the price of multi-vendor
standarization. Or of the compatibility requirements of success. Or
of downsizing. Or something.
> In short, it occupies the same location in C#'s
> type lattice as Object, but it has some additional conversions defined
> that are not subtype relationships.
That's exactly what I am trying to do, if what you mean by "same
location" is "peers at the same depth". If they were truly at the
same location in the type lattice, wouldn't they be the same type?
Perhaps I'm missing something here.
Thanks for the prompt and incisive comments, Neal.
More information about the coin-dev