On 06/26/2012 12:37 PM, Jochen Theodorou wrote: > Am 26.06.2012 11:59, schrieb Rémi Forax: >> On 06/26/2012 11:40 AM, Jochen Theodorou wrote: >>> Hi all, >>> >>> just to be sure I understand correctly... afaik there are two things >>> invokedynamic cannot do. >>> >>> (1) calling private methods >>> actually I am not sure this is really true. There is a Lookup instance I >>> can use to get handles to private methods (afaik), therefore it should >>> be possible. Or is there an artificial restriction of some kind? >> No restriction, or you need a way to get the proper lookup >> or you use reflection to get a j.l.r.Method, call setAccessible(true) >> and unreflect it as a MethodHandle (see MethodHandles.unreflect*). > ok, so I can remove those stupid helper methods ;) > >>> (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. > > > but not super(). >> It's because the VM verifies that you should not have access to an >> uninitialized object, ie. access to an object before calling super(). >> So if you do a super() using a MethodHandle, because it's hidden >> by an invokedynamic (or a constant method handle) the VM as no >> way to know that this invokedynamic will call the constructor >> of the super class, so the verifier will not let you call invokedynamic >> on this in a constructor without calling explicitly super() before. > I see... that is a bit unfortunate. I have to do quite some tricks to > enable the super constructor call according to Groovy rules for method > dispatch. And what I do I won't call fast. 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. > > bye blackdrag > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
