Hi Peter,
Thanks for the review. This code path is critical in this core
reflection implementation and I want to resolve this bug with a low risk
fix in an update release and thus the proposed fix. Thanks for the
experiment with MethodHandles and finding out the pecularity. As a
side note, I really look forward to the reflective method call being
reimplemented with method handles (great to see your prototype).
I have incorporated Alan's and your comment. Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk7u/webrevs/8021368/webrev.01/
Mandy
On 12/14/2013 6:09 AM, Peter Levart wrote:
Hi Mandy,
I tried the following:
public class Test {
static class A {}
static class B {}
static class X {
public void x() { }
}
static class Y extends X {
public A a(B b) { return null; }
public B b(A a) { return null; }
public void x() { }
}
public static void main(String[] args) throws Exception {
MethodHandles.Lookup lookup = MethodHandles.lookup();
MethodHandle mh = lookup.findVirtual(Y.class, "x",
MethodType.methodType(void.class, new Class[0]));
MethodHandleInfo mhi = lookup.revealDirect(mh);
System.out.println(mhi.getDeclaringClass() == Y.class);
}
}
The above code does not trigger loading of classes A or B. But
unfortunately it prints true even if I comment-out the declaration of
method Y.x(). I don't know if this is a bug though. I should ask on
the mlvm-dev list...
Anyway, your approach seems more appropriate as it doesn't depend on
method handles and their peculiarities...
Some nits:
2241 * Finds the checkMemberAccess method of the given
SecurityManager*instance*.
...I think it should read "...of the given SecurityManager*class*." instead,
since the method parameter is of type Class.
2210 private static class SecurityManagerHelper {
2211 private final SecurityManager smgr;
2212 private final boolean overrideCheckMemberAccess;
...the fields could be declared package-private so that no synthetic access
methods are generated...
Regards, Peter
