two things invokedynamic canbot do

[Attila Szegedi]

Just out of curiosity, in what situation would you need to have an invokedynamic vs. invokespecial call to super <init>? Need invocation time overloaded constructor resolution?

Attila. 

2012.06.26. dátummal, 12:37 időpontban Jochen Theodorou <blackdrag at gmx.org> írta:

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