Review request for 8021368: Launch of Java Web Start app fails with ClassCircularityError exception
Mandy Chung
mandy.chung at oracle.com
Sun Dec 15 01:02:16 UTC 2013
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
>
More information about the core-libs-dev
mailing list