On Apr 25, 2013, at 8:58 AM, "MacGregor, Duncan (GE Energy Management)" <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(). John and I referred to this method yesterday as: Lookup.ununreflect() ;-) -- Chris > > 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
