> On Oct 17, 2016, at 4:30 PM, Peter Levart <[email protected]> wrote:
>
> ...you 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")
> .allowed(PROTECTED_INSTANCE_F_M, PUBLIC_INSTANCE_F_M,
> PROTECTED_STATIC_F_M,
> PUBLIC_STATIC_F_M, PUBLIC_C)
> .denied (PRIVATE_INSTANCE_F_M, PACKAGE_INSTANCE_F_M,
> PRIVATE_STATIC_F_M,
> 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
>
> ...is a reassurance that the patch does exactly what it should. No less,
> no more.
>
Indeed.
>
> 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 ?
>
PACKAGE_CLASS_IN_PKG_A
PUBLIC_SUPERCLASS_IN_PKG_A
PUBLIC_SUBCLASS_IN_PKG_A
> 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?
Mandy
