Converting MethodHandle into reflective Method instance

[MacGregor, Duncan (GE Energy Management)]

There is no public API for such introspection, and I think there's strong
desire not to introduce one (though a private one is used in the Java 8
lambda factory). However even if there is one I don't think it would solve
your problem. The call site created by a bootstrap method will normally
change its own target during execution into a a guardWithTest chain which
would dispatch to several targets, and when it gets too big for that may
start fetching and directly invoking other method handles or passing them
back to an exact invoker.

I think your only real option is intercept the calls that get the method
handles in the first place, so you'd need to transform most calls to
Lookup objects and unreflect(). That shouldn't be too hard a bit of code
transformation to do.

Regards, Duncan.

On 10/01/2013 16:17, "Eric Bodden" <eric.bodden at ec-spride.de> wrote:

>Hi all.
>
>The Lookup class contains an "unreflect" method which converts Method
>objects into MethodHandles. I am lookingo for something that does just
>the opposite and I wonder if the JDK provides this functionality or if
>otherwise you would accept a patch from us such that it did.
>
>Our motivation for this is as follows. We are trying to extend the
>AspectJ compiler such that it allows the runtime to match method-call,
>field-set and field-get pointcuts against invokedynamic instructions,
>so that effectively a pointcut such as call(* foo()) would match also
>if "foo" is called via invokedynamic.
>
>Our current design for this is as follows:
>We wrap all original bootstrap methods into a wrapper which (a)
>invokes the original bootstrap code, (b) retrieves the method handle
>returned by that bootstrap code and matches it against all pointcuts
>of all aspects and if any pointcuts do match then (c) returns a
>modified method handle that implements the intended advice-execution
>logic.
>
>Steps (a) and (c) seem to work quite smoothly but (b) is giving us
>trouble. This is because, to match AspectJ pointcuts at runtime, we
>would like to use ajc's weaving API:
>http://eclipse.org/aspectj/doc/next/weaver-api/org/aspectj/weaver/tools/Po
>intcutExpression.html#matchesMethodCall(java.lang.reflect.Method,
>java.lang.Class)
>This API requires jva.lang.reflect objects and has no knowledge of
>MethodHandles. Hence the need for a converter.
>
>I do realize that not every kind of MethodHandle may actually *have*
>an appropriate Method object, as not every MethodHandle actually
>points to a method. But it would be great to have a getMethod() method
>for those that do, or a getField() method for those that represent
>field accesses.
>
>Any pointers in this direction would be appreciated. Also, if you
>think that what I am after will *not* be possible for some reason, it
>would be great if you could let me know that, too.
>
>Best wishes,
>Eric Bodden
>-- 
>Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
>Head of Secure Software Engineering Group at EC SPRIDE
>Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
>Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>_______________________________________________
>mlvm-dev mailing list
>mlvm-dev at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev