jdk7 b58, VM doesn't smell good

[John Rose]

On May 12, 2009, at 3:46 PM, Rémi Forax wrote:

> I've found that if you convert the leading argument of the method  
> handler,
> you have to cast the leading argument of MethodHandle.invoke() too.

Yes, that's because method handle invocation sites do not allow  
variation in the target method handle's type, not even covariant  
argument type changes or contravariant return type changes.

Sorry about your code.  The root cause is that the resolution of the  
type signature for MH.invoke is done relative to MH itself (which  
would be correct if MH actually statically declared its invoke  
methods).  Since MH is on the BCP, and your app class is on some other  
class loader, MH cannot resolve type names from your app in the  
signature of its invoke methods.  That's why b59 erases non-BCP  
receiver types in findVirtual.  Yuck.

I find it slightly annoying anyway (even if this bug did not exist)  
that findVirtual(my.random.class, "foo", t) returns a MH whose type  
leads off with my.random.class.  This class may in fact by an  
anonymous class whose identity I don't care about (in the case of  
MHs.bind), so it's hard to see what I gain from being so exact about  
the type.  Of course, if I'm doing  
findVirtual(my.important.and.public.api.interface.or.class, "foo", t),  
I probably do want to know about the type of the leading argument.  So  
I don't see that there's a cleanup to be done at this point in the API.

-- John

P.S.  Having method handles auto-convert among "reasonably similar"  
method-tyeps is implementable, but it would slow down every method  
handle call, unless we were to institute a static type checking system  
that the verifier would enforce.  Today's reality is dynamic type  
safety checks, and complicating that check (which is currently a  
single pointer comparison) would have questionable benefit.  This is  
because dynamic languages do not follow the covariant/contravariant  
conventions of statically typed functional languages.  (I would prefer  
to call dynamic call sites "malvariant" in recognition of the fact  
that they usually vary, but half the time in the wrong direction, as  
in the canonical case of a call of type (Object)->Object.)  Moreover,  
the type conversions that dynamic languages require are not obviously  
aligned with any particular theory of function types; for example,  
auto boxing and unboxing are important features for dynamic languages,  
and it would be a long stretch to call these conversions subtype  
relations.