By John.Rose-Oracle on Dec 23, 2010
Here are some of the differences you might notice:
- The class
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
- The class
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
- The class
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.
- Direct syntax support for generating
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
- Some of the documented argument conversions for method handles are not well supported, especially those involving unboxing or boxing, or primitive widening or narrowing. You can run into this easily by passing a primitive value to
invokeGeneric. As a workaround, try casting the offending primitive to
Objectat the call site. This is bug 6939861.
- Some of the method handle combinators (aka. transformers) will fail if you work with more than about 10 arguments at a time. This is bug 6983728.
- Your item here: If you notice other changes that disturb your code, please let me know, so I can adjust this list.
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:
- The JVM flags
-XX:+EnableMethodHandleswill be turned on by default. (This is tracked by bug 6817525.)
- The JVM flag
-XX:+AllowTransitionalJSR292will be turned off by default, causing constant pool tag 17 to be rejected.
- The class
java.dyn.Switcherwill be renamed
java.dyn.MethodHandlesmay change, losing the overloadings which take
- The variable-arity “hook” for
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.)
- Any remaining stray
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.)
- A few items are marked “provisional” in the javadoc; these could still change also.
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.