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*). > > (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() 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. > > Am I right about those? > > bye blackdrag > > Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
