PROPOSAL: language support for JSR 292

[Rémi Forax]

John, your proposal doesn't cleanly separate the four parts of the proposal
thus this is really hard to read (at 2 am :)

Correct me if i'm wrong,
the purpose of Dynamic as a type is to
1) be able to do an invokedynamic wich is receiverless using a dot.
    Dynamic x=...
    x.m() // is translated to invokedynamic m(Dynamic)
2) to have more conversions from/to Dynamic than from/to Object.

Else, I would prefer null not being infered as Void instead
the compiler should raise an error and let the user cast it
to Object, Dynamic etc.

Rémi

Neal Gafter a écrit :
> John-
>
> 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) 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.
> If the answer is yes, then it must have Object as a supertype.  You
> might find it useful to review what C# has done in this area with
> their type "dynamic".  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.
>
> I don't believe this is a "small change".  However, if it is going to
> happen anyway in JDK 7 to support jsr292, I can see the sense in
> having it dealt with in the same expert group as four or so other
> small, local changes.
>
> Regards,
> Neal
>
> On Sat, Mar 28, 2009 at 11:53 PM, John Rose <John.Rose at sun.com> wrote:
>   
>> Hello, colleagues.  Here is a proposal which is linked to JSR 292
>> (invokedynamic).
>>
>> http://wikis.sun.com/display/mlvm/ProjectCoinProposal
>> http://blogs.sun.com/jrose/entry/jsr_292_support_in_javac
>>
>> Here's the teaser (from my blog):
>>
>> In order to work with dynamic types, method handles, and invokedynamic
>> I have made some provisional changes to javac as part of the Da Vinci
>> Machine Project. The mlvm wiki has a full description for Project
>> COIN. It is most desirable, of course, to program invokedynamic call
>> sites as Java expressions, not just ASM code, and that's what those
>> langtools patches are for.
>> The essential features are four:
>>
>>        • The type java.dyn.Dynamic will accept any method call and turn it
>> into an invokedynamic instruction, and the full range of such
>> instructions can be spelled from Java code.
>>        • The type java.dyn.MethodHandle will accept any argument and return
>> types for a call to the method named invoke, which means that Java
>> code can spell the full range of method handle invocations.
>>        • The full range of bytecode names acceptable to the JVM can be
>> spelled from Java code, using an exotic identifier quoting syntax.
>>        • The type java.dyn.Dynamic serves as a bare reference type: Anything
>> implicitly converts to it, and it can be cast to anything, but it is
>> not a subtype of java.lang.Object. Its methods, of course, are those
>> from point #1, so it is handy for forming invokedynamic calls.
>> The rationale is pretty simple: If we put some minimal support into
>> Java for defining and using names in other languages, then Java can be
>> used as a system programming language for implementing them.
>> Otherwise, the system programming language will be assembled bytecode.
>> (I like to visit ASM, but don't want to live there.)
>>
>> Do check out the wiki page; it has the full Project COIN proposal
>> format.
>>
>> Best wishes,
>>
>> -- John Rose (Da Vinci Machine Project)
>>
>>
>>     
>
>