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. _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
