Crash with invokeDynamic on MethodMissing attempt
John Rose
John.Rose at Sun.COM
Mon May 18 19:46:35 PDT 2009
On May 18, 2009, at 6:57 PM, Yehuda Katz wrote:
> I've pretty much achieved everything I was trying to do last night: http://gist.github.com/113717
Congratulations!
> Ideally, I'd like to be able to do something like:
>
> Object invoke(DynamicTester tester, Object... objects) {
> return target.invoke(tester, name, objects);
> }
>
> Where the original method could be methodNotFound(name, String...
> name) or whatever.
>
> Again, I'm relatively new to all this, so I'm pretty sure what I
> want to do is either a big no-no or a no-brainer.
It's a common use case: You have an indy site with a specific type
(e.g., (String)->String) and you want to route calls from there to a
generic method. The way to make up the difference between method
handles types (calling sequences) is to use one of MethodHandles.
{convert,spread,collect}Arguments.
In your use case (as is common) there are two method handles in play,
the ultimate target (the handle to methodNotFound), and the immediate
target (your MethodMissingHandle object). Either (or both) might
differ in their type from the call site's type. In that case, the
difference must be made up with one of the *Arguments calls.
BTW, as a matter of style, if a class defines methods which are
expected to be used via method handles, and by multiple clients, it's
probably a good idea for the class to provide access to those methods
in the form of method handles, whether or not it also provides them as
directly callable (named) methods. E.g.:
public class DynamicTester {
public String methodNotFound(String name, String extra) {
return name + extra;
}
public static final MethodHandle METHOD_NOT_FOUND = ...;
// OR:
public MethodHandle methodNotFound() { return /*private*/
METHOD_NOT_FOUND; }
}
-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090518/714a4036/attachment.html
More information about the mlvm-dev
mailing list