Lambda and JSR 292 method handle

Rémi Forax forax at univ-mlv.fr
Fri Dec 18 09:07:53 PST 2009


Le 18/12/2009 16:28, Neal Gafter a écrit :
> On Fri, Dec 18, 2009 at 6:48 AM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     Le 18/12/2009 15:41, Neal Gafter a écrit :
>
>         Do the types representing jsr292's JavaMethodHandle obey subtype
>         relationships that make them covariant on return type and
>         contravariant on
>         argument types?
>
>
>     Yes, if they are invoked using invokeLambda() and no other invoke*.
>     For the record, even if this could changed, there are two other
>     method invoke*,
>     invokeExact that requires the exaxct same signature and
>     invokeGeneric that is able
>     to do conversion like boxing/unboxing etc.
>
>
> This doesn't answer my question.

Sorry I was not clear.

> I'm taking about subtyping among values of function type, not about 
> the invocation point.  Specifically, it should be the case that, given
>
> *#Object(String) f1;*
> *#String(Object) f2 = ...;*
>
> you can assign
>
> *f1 = f2;*

#Object(String) and #String(Object) are both erased to 
java.dyn.MethodHandle,
so there is no conversion:
*
MethodHandle f1;
MethodHandle f2 = ...
f1 = f2;

*Now when you invoke f1 with a String, because subtyping is allowed when 
invoking,
the VM will be able to call f2.*
*
>
> This needs to be a subtype conversion (e.g. no code should have to be 
> generated for this conversion to occur) for reasons that I can explain 
> if it is not already clear.  The ParallelArray APIs take advantage of 
> this kind of subtyping by defining its function types using interfaces 
> and wildcards.  If that API is recast using function types, some 
> flexibility will be lost unless function types act this way too.
>
> The answer may depend on /how/ function types are mapped to 
> JavaMethodHandle.

Function types are mapped to one unique type: java.dyn.MethodHandle, not 
JavaMethodHandle.
JavaMethodHandle is a special subtype that can be used to translate some 
lambdas.


> There is no public proposal on the table yet for how that would work.  
> I hope the anonymous experts inside Sun that Mark suggested are 
> devoted to this work are on it.

So am I :)

>
> Cheers,
> Neal
>

cheers,
Rémi


More information about the lambda-dev mailing list