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/MethodHandleInfo.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
