Here is an update on the method handle cracking API. Though we will probably make some small adjustments, it appears to be converging.
http://cr.openjdk.java.net/~jrose/8008688/specdiff.02/ http://cr.openjdk.java.net/~jrose/8008688/javadoc.02/ Key points: - interface MethodHandleInfo (MHI) presents a "cracked" symbolic reference for the member underlying a direct method handle (DMH) - cracking of method handles which are not DMHs is left for the future - you need the original Lookup object associated with DMH creation in order to crack it; this prevents side-channels - there are access methods for the four components (ref kind, class, name, type) of the CONSTANT_MethodHandle (or equivalent information) that was used to create the DMH - there is a bridge (asMember) from MHI to the Core Reflection API (can be built by user but very complex) - there is a fast path to the modifier bits of the underlying member (for checking public, varargs, etc.) - there are two static utility methods on MHI, toString and getReferenceKindString - there is also an unchecked version of the cracker (revealDirectAsAccessibleObject), which always makes a security manager call and bridges directly to the Core Reflection API - Modifier.isVarArgs and Modifier.VARARGS are made public, because there was no standard test, and variable arity is a key MethodHandle property The implementation patch is refreshed: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-info-8008688.patch Changes since last E-mail: - added revealDirectAsAccessibleObject - revealDirectAsAccessibleObject performs the same strong SM check as setAccessible - when either revealDirect function is called on a non-DMH, you get NoSuchMethodException - refined the types and documentation of exceptions and throws - removed static methods from MHI, except getReferenceKindString and toString - moved isVarArgs to java.lang.reflect.Modifier, where it belongs Possible loose ends: - minor name changes - MHI.toMember needs a more precise spec, and the default method is dodgy - could change ReflectiveOperationExceptions to IllegalArgumentExceptions, since the range of possible ROEs is quite limited — John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
