method handle cracking API

[John Rose]

On Apr 25, 2013, at 8:58 AM, "MacGregor, Duncan (GE Energy Management)" <duncan.macgregor at ge.com> wrote:

> I would have thought one of the most common uses of breaking down a method
> handle like this would be to immediately turn it into a java.lang.reflect
> object and maybe examine annotations or exception information. So although
> I don't think it should extend Member I do think it should have a standard
> way to return a Member, sort of the opposite of Lookup.unreflect().

Good point.  Yes, the annotations will be useful.

My current concern with this is driven by the rather creative use of invokedynamic in Project Lambda.

They represent a closure creation ("capture") point by an indy instruction, with an extra BSM argument to specify which interface API is being implemented, and an extra BSM argument to represent which private method is providing the implementation.  Both of these BSM arguments are naturally represented by CONSTANT_MethodHandle.  But the BSM needs to crack those MHs down to their components, for various reasons.

As you point out, this technique could be extended by making the BSM sensitive to annotations and other metadata.  For example, a lambda for a BinaryOperator that is associative and/or has an identity could be marked (internally) with an annotation on the private method that contains the operator. This would give a back-door way to classify operators.

> As for transformed method handles a cracking interface may not need to
> return an representation of the original structure, it might be enough to
> return the parts that remain (both method handles and bound objects) as I
> would guess that would be enough for debugging purposes and resource leak
> hunting.

I agree with that.  But it will be very hard to write a specification that promises anything concrete, and therefore almost impossible to write conformance tests.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130425/8ac9249b/attachment.html