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().
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. Regards, Duncan. On 24/04/2013 08:02, "John Rose" <john.r.r...@oracle.com> wrote: >Those of you who have been following 292 details may have noticed the >type java.lang.invoke.MethodHandleInfo show up in support of Project >Lambda. > >The 292 EG has been thinking about the problem of method handle >reflection, since JDK 7, in background mode. We are sure we want >something that can "crack" direct method handles, and not ready to >venture anything more elaborate. > >(Arbitrarily transformed method handles probably can never have an >implementation-independent cracked form, so there are real problems >specifying a cracking function that is defined for every method handle. >For example, recording the series of transforms that gave rise to every >MH rules out many interesting implementations, and recovering a "likely" >series of transforms for a MH seems perilously close to the >function-equivalence problem, which we know is undecidable.) > >I am working on polishing this restricted cracking API for direct method >handles. Here is a webrev of it, starting at MethodHandleInfo: > >http://cr.openjdk.java.net/~jrose/8008688/javadoc.00/java/lang/invoke/Meth >odHandleInfo.html > >Comments would be welcome. > >Thanks, >‹ John > >P.S. No testing yet; it is doc-ware at the moment. I just posted a >checkpoint of the source patches here: > >http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-info-8008688.patch > >P.P.S. Here are my fix-me comments at this point: > >// Should this extend java.lang.reflect.Member? (default: no) >// Should we include getModifiers? (default: no) >// Should the direct parts be separated into a sub-interface (to allow >for future extensions)? >// If we don't have a subinterface, later on we might need an isDirect >method. >// If we do have a subinterface, then MethodHandleInfo becomes an >empty type (like java.lang.reflect.Type). >// Define SecurityManager checks. (TO DO) > >_______________________________________________ >mlvm-dev mailing list >mlvm-dev@openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
