Le 17/01/2010 13:49, Jochen Theodorou a écrit :
Hi,
Imagine there is
class A {
public int x(){return 1;}
}
class B extends A {
public int x(){
return super.x()+1;
}
}
to solve cases like that in Groovy we have to generate a call stub for
A#x in B, that allows calling x' as super.x(). That is because
Reflection does not provide any terms of handling this, since if in
Reflection I would try to invoke the method A#x with a B, I would get
B#x invoked and not A#x. Since that again recently was brought to my
attention I was asking myself if MethodHandles do solve that case or
not. Especially all that talking about invoke exact, generic and
whatever makes me wonder right now. Of Remi's having a backport for
MethodHandels, then I wonder how this case is supposed to be solved,
since Reflection cannot be used for this. Dynamically generating a
subclass of A and then sending the call through that subclass instead
of doing super.x() in B would seem like a possible solution... Only I
fear restricted environments forbidding this kind of thing at runtime.
If then at sompile time we didn't take counter measures already, then
at runtime it is too late to do anything and I would prefer not having
people to loosen their security managers for that.
If MethodHandles solve that I failed to see how exactly. If they don't
solve it, then I think it is a problem.
bye Jochen
JSR 292 API already solves this problem :
It depends how you create a method handle,
if you create it with MethodHandles.lookup().findSpecial(...)
the semantics of mh.invoke() is invokespecial,
if you create a mh with MethodHandles.lookup().findVirtual(...)
the semantics of mh.invoke() is invokevirtual.
see
http://download.java.net/jdk7/docs/api/java/dyn/MethodHandles.Lookup.html#findSpecial%28java.lang.Class,%20java.lang.String,%20java.dyn.MethodType,%20java.lang.Class%29
The backport as currently no support for that.
If you try call findSpecial on a Loookup, it throws a not implemented
exception :(
The plan is to change the bytecode blob at method handle call site to
issue a invokespecial,
but it will only works if the VM supports class rewriting.
There is another way to support that, you can generate a bridge method
and create a
reflection method on it.
class A {
public int x(){return 1;}
}
class B extends A {
public int x(){
return bridge$super$x.invoke()+1;
}
private int bridge$super$x() {
return super.x();
}
private static final Method bridge$super$x;
static {
bridge$super$x = B.class.getDeclaredMethod("bridge$super$x", null);
}
}
Rémi
--
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.
