heads up: MH invocation syntax change

John Rose john.r.rose at oracle.com
Thu Aug 26 16:23:10 PDT 2010


I have just pushed code to mlvm/{langtools,jdk} which reflects the following syntax change for method handle invocation:

  T x = mh.<T>invokeExact(...);
=>
  T x = (T) mh.invokeExact(...);

and:

  {mh.<void>invokeExact(...);}
=>
  {mh.invokeExact(...);}


In other words, we are replacing fake type parameters (void? int?) with real casts, as a better notation for the intended type of the MH invocation.

The old format still works temporarily in a compatibility mode, unless you turn off the compatibility mode.  If you want to compile your code in the strict mode, to catch old usages, compile like this:

 $ javac -XDallowTransitionalJSR292=no

At some point before JSR 292 PFD, the default will change, and the flag will be required to support the type parameter syntax:

 $ javac -XDallowTransitionalJSR292=yes

Warning:  The treatment of the "<void>" case is potentially a code-breaking change.  To avoid the breakage, you have to force your invocation statement to produce an explicit value:

  {mh.invokeExact(...);}
=>
  {Object junk = mh.invokeExact(...);}

See the paragraph in JLS 14.8 "Expression Statements" containing the phrase "such a trick" for discussion of this corner of the language.

Updated language rules are documented here:
  http://wikis.sun.com/display/mlvm/InterfaceDynamic

These rules are provisional, but I expect them to replace the old ones, which did more violence to the language.

Best wishes,
-- John

P.S. Similar changes apply to InvokeDynamic, which also has a statically checked requirement for an enclosing @BootstrapMethod annotation.  If you have been (a) writing InvokeDynamic invocation syntax in Java source code, or (b) spinning invokedynamic bytecodes, the recent addition of local bootstrap methods is a change you'll need to catch up with soon.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100826/91f0c8f6/attachment.html 


More information about the mlvm-dev mailing list