On 04/25/2013 08:39 PM, John Rose wrote: > On Apr 25, 2013, at 8:58 AM, "MacGregor, Duncan (GE Energy > Management)" <duncan.macgre...@ge.com > <mailto:duncan.macgre...@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
