Here are some of the differences you might notice:
CallSiteis now abstract, causing an
InstantiationErrorif you try to make one directly, or a problem with a
supercall if you make a subclass. This breaks a bunch of old code, including mine. The Expert Group decided to refactor
CallSiteinto three subclasses:
VolatileCallSite. To fix your code, replace
CallSiteby one of the subclasses, probably
invokedynamicinstruction should point to a constant pool entry of type 18, not 17 (a tag that is now deprecated) or 12 (the name-and-type required by the Early Draft Review). The first component of this constant pool entry must be an index into the new attribute
BootstrapMethods. For the moment, tag 17 is supported, under the JVM option
java.dyn.Linkageis deprecated and going away. In particular,
registerBootstrapMethodis going away, because the class file format now support static, per-instruction registration, via the
java.dyn.JavaMethodHandleis gone. Use
Lookup.findVirtual(cached in a private static final) and
MethodHandle.bindToto convert a random object to a method handle. Use
MethodHandles.asInstanceto convert a method handle to a random SAM interface.
invokedynamicinstructions in Java code will not be part of JDK 7. (Sorry! Use indify instead.) Exotic identifiers are also out for now, as is the annotation-based BSM specification. We will continue to experiment with these things in the mlvm repository, and some may be adopted into the Lambda project. In fact, we hope that Lambda will integrate method handles somehow, at least providing a way to construct a method handle from a literal expression like
invokeGeneric. As a workaround, try casting the offending primitive to
Objectat the call site. This is bug 6939861.
It is still the case that you must pass the following options to the JVM to use JSR 292:
Here are a few more changes that are very likely in the near future:
-XX:+EnableMethodHandleswill be turned on by default. (This is tracked by bug 6817525.)
-XX:+AllowTransitionalJSR292will be turned off by default, causing constant pool tag 17 to be rejected.
java.dyn.Switcherwill be renamed
java.dyn.MethodHandlesmay change, losing the overloadings which take
withTypeHandleris controversial among JVM implementors and may be adjusted or deleted. (To see what variable arity means for method handles, see the method
arityOverloadaround line 1423 in SIOC.java.)
sun.dyn.\*names in the API are going away, of course.
MethodHandlewill not have a superclass. (Nor will it have user-callable constructors for building subclasses.)
At year’s end I am deeply grateful to the JSR 292 Expert Group, intrepid early adopters (Dan H., Rémi F., Charlie N., Fredrik O., Jim L., Sundar!), mad scientists (Thomas W., Lukas S., Hiroshi Y.!), conference propagandists (Christian T., Brian G., Alex B., Chanwit K.!) and the whole MLVM community for their enthusiastic, deeply technical contributions to the future of the JVM. Thank you all for the excellent journey so far.
Please accept my personal warm best wishes for a merry Christmas and a happy New Year.