two things invokedynamic canbot do

[Jochen Theodorou]

Am 26.06.2012 13:06, schrieb Rémi Forax:
[...]
>>>> (2) calling super()
>>>> afaik I cannot generate a call site that replaces the invokeSpecial call
>>>> to a super class constructor.
>>> You can call super.foo()
>> ah true... this is not reflection.. even if I get the handle from the
>> super class it won't call the overriding method in the current class. I
>> totally forgot... how do you handle this in your backport?
>
> I don't :(
>
> The current plan is to add an empty trampoline method in the code
> by default and to redefine the code of this method when you create
> a method handle that use invokespecial.
> But it only works in agent mode not in reflection only mode.

it works only in agent mode for you because you add the methods at 
"runtime" I guess. We let the compiler emit those, so we don't depend on 
an agent... but of course it means the bytecode is quite a bit larger 
than needed. Ah well..

[...]
> For Dart, I don't generate Dart constructor as Java constructor,
> I create public default Java constructor that just call super()
> and translate the Dart constructor to a Java method.
>
> Then, a call to new is translated to an invokedynamic that will,
> at runtime, fold the call to the Java constructor and the call to
> the method that correspond to the Dart constructor.
>
> This allow me to workaround the VM limitation but
> I don't allow any Dart to Java integration like being able
> in Java to inherits from a Dart class.

I see, well, that is no option for Groovy then. Too bad there is no 
other way around

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org