John Rose wrote:
The JSR 292 EG was talking about corner cases for method invocation, specifically the invocation of dynamically selectable superclass constructors. Although this probably does not admit of a direct solution (without breaking the verifier's protections), the conversation leads to the concept of a "categorical superclass". I'm pretty sure a number of people on this list have worked out the details. It would be good to discuss this, and see if method handles and invokedynamic can play a supporting role.
is there anything explaining a little bit more detailed what a "categorical superclass" is?
[...]
For example, every non-final method S.m(T) will have two features in M, one corresponding to the binding of m(T) in S, and one "pluggable" feature which defaults to S.m(T) but which can be overridden (for an instance of M) to another method (specified as a method handle or an override in an anonymous subclass of M). There are two features because even if M specifies an override for m(T), there must be a way for the override code to access the original S.m(T) to emulate "super.m(...)".
MethodHandles cannot do that? Why not doing the invocation through a MethodHandle in general there? Per default it would be the one calling super in the end... or if exchanged it would be the one we placed in.
[...]
Constructors are trickier, since the verifier makes special demands on the shape of their code. It's not enough to say "invoke a method handle from M", since that makes it impossible for the verifier to ensure, for any constructor in K, that exactly one constructor in S (or K) has been invoked before the rest of the constructor body is executed. Basically, K's constructors have to pass the verifier, but they cannot constrain future users of K beyond the limits naturally imposed by the constructors of S.
you mean you want to enable super(x,y), and super has no constructor that could take x or y?
Groovy does not allow for such things atm. When we encounter a super(...) call, then we go into a switch construct, and ask the MOP about which constructor to invoke. This of course requires us to write the constructor calls into the bytecode... there is no other way atm, the doubled meaning of register 0 does not really help in this respect.... anyway... most of the time this works good enough for us. So what we do is basicallylet the MOP return the constructor number (defined by sorting) and modifying the arguments in an array. For the actual call we then unpack the array and make the call native. If someone is adding a new constructor, then this constructor cannot be used by super(...), but it can be used through "new ..."
btw... I think the state with MethodHandles was, that they cannot call to an overridden super method.. please correct me if I am wrong here. Sure, there is an easy solution for this, just create a helper method to do that job for you... but it bloats the bytecode extremely. More bytecode means longer class loading and verification times and more work for the JIT. It would be nice to not to have this restriction
bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
