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