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? > 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. 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
