method handle cracking API

[Remi Forax]

On 04/25/2013 08:39 PM, John Rose wrote:
> On Apr 25, 2013, at 8:58 AM, "MacGregor, Duncan (GE Energy 
> Management)" <duncan.macgregor at ge.com 
> <mailto: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.

and if javac is able to generate such invokedynamic ...
you have a tool which is too powerful to even think about it.

>
> — John

Rémi