Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

Mandy Chung mandy.chung at
Mon Oct 17 23:51:24 UTC 2016

> On Oct 17, 2016, at 4:30 PM, Peter Levart <peter.levart at> wrote:
> would review the members that are allowed and then you should ask yourself: "Which are the ones that are denied? All the rest. What are they?", or: "Could there be any other that should be allowed? Which one?”

I’m happy with your revised patch that group field/method together and adding allowAll/denyAll that makes it easier to understand while it does not lose any information.

> It's much easier if they are explicitly listed:
>          ok &= new Test()
>              .current("b.PublicSub").member("a.PublicSuper").target("b.PublicSub")
>                       PUBLIC_STATIC_F_M, PUBLIC_C)
>                       PACKAGE_STATIC_F_M, PRIVATE_C, PACKAGE_C,
>                       PROTECTED_C)
>              .perform();
> And besides, you don't really have to review them all.

I do review them as this test is one important part of this patch :) 

> The fact that running the test on unpatched JDK 9 finds just two differences:
> - access to protected static method from subclass in another package
> - access to protected static field from subclass in another package
> a reassurance that the patch does exactly what it should. No     less, no more.


> Then I would have to have a mapping from class name -> constant name for the generator.

This is one time thing.

> Besides, constant names would not be any prettier than class name string literals. At least now it is obvious to anyone what package a particular class belongs to:
>     "a.Package" vs. A_PACKAGE ?


> Note that I can't use a.Package.class literal(s) here (thought I would like to) as they don't compile if they refer to a package-private class from another package.
> I would like to keep those things unchanged, If you don't mind.

Do the suggested variable names help?


More information about the core-libs-dev mailing list