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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
