InvokeDynamic

Daniel Latrémolière daniel.latremoliere at gmail.com
Sat Apr 30 00:51:36 PDT 2011


I suggest a syntax for InvokeDynamic. It is created like a field and has 
a name (for referencing and bootstrapping it), then i suggest to create 
a new modifier "dynamic" and define InvokeDynamic like a mix of field 
and constructor with his bootstrap code included in it, like this:

|{public|protected||private} {static||*dynamic*} {final||volatile} 
$name*(MethodHandles.Lookup caller, MethodType type)* {
     // code creating MethodHandle "value" variable.
*target* value;
}|

You can see the three following differences with a field:

    * A new modifier ("dynamic") usable in the same places than current
      "static" modifier. All others modifiers are like a standard field.
    * The field has arguments like a constructor with his execution
      context. The two arguments of the bootstrap/constructor are fixed.
    * In this type of dynamic field constructor, the normal (without
      exception) end of code is "target" instruction.

The bootstrap method return a MethodHandle, because the type of CallSite 
is not used given the others modifiers of the field definition:

    * final => ConstantCallSite
    * "nothing" => MutableCallSite
    * volatile => VolatileCallSite

Given this syntax, there is no need (except for reflection) of exposing 
CallSite and using a bootstrap method (no name wasted for referencing 
another bootstrap method).

For the eye of developer, this will visibly be a dynamic field with a 
constructor, then reasonably corresponds to InvokeDynamic features.

Opinions?

Daniel.

NB: It is not special in Java to have different content in a code 
following context: a constructor allow instructions like "this(...)", or 
"super(...)", contrary to a standard method, then "target" instruction 
at the end of code will not be really alien.

-- 

Daniel Latrémolière
Mail: daniel.latremoliere at gmail.com <mailto:daniel.latremoliere at gmail.com>

//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110430/7d1be092/attachment.html 


More information about the mlvm-dev mailing list