Nestmate same-package check

[David Holmes]

On 20/04/2017 12:42 PM, John Rose wrote:
> On Apr 18, 2017, at 11:42 AM, Dan Smith <daniel.smith at oracle.com
> <mailto:daniel.smith at oracle.com>> wrote:
>> I've uploaded a draft of JVMS changes for JEP 181 "Align JVM Checks
>> with Java Language Rules for Nested Classes" to:
>> http://cr.openjdk.java.net/~dlsmith/private-access.html
>
>> classHasValidNest(Class) :-
>>
>> classMemberOfNestName(Class, HostName),
>> classDefiningLoader(Class, L1),
>> loadedClass(HostName, L1, HostClass),
>> samePackageName(Class, HostClass),
>> classClassName(Class, Name),
>> classNestMemberNames(HostClass, MemberNames),
>> member(Name, MemberNames),
>> classDefiningLoader(HostClass, L2),
>> loadedClass(Name, L2, Class).
>
> In English:
>
> When validating nestmate attributes, if a class C with name
> "C" has an attribute MemberOfNest("H"), it is valid only if the
> following are all true:
>  1. The string "H" resolves from C's loader (L1) as H.
>  2. The strings "C" and "H" have the same package prefix.
>  3. H contains an attribute of the form NestMembers(…"C"…).
>  4. The string "C" resolves from H's loader (L2) as C.
>
> Steps 1 and 4 are both CONSTANT_Class resolution operations.
> Step 3 is a simple search of a symbol list, which is easy.
>
> This logic can be simplified by testing that C and H must
> be in the same runtime package.  In that case, L1 and L2 are
> identical, and step 4 becomes:
>  4'. C and H have the same defining loader.
>
> Then we can refactor 2 and 4' into a more direct check on
> runtime package (using the functor 'sameRuntimePackage'):
>  1. The string "H" resolves from C's loader (L1) as H.
>  2'. C and H have the same runtime package.
>  3. H contains an attribute of the form NestMembers({... "C", ...}).
>
> This is a simpler specification, and it also closes any possible
> loopholes in package/nest alignment by insisting on equal
> runtime packages from the start.
>
> It also avoids a possibly wasteful class loading step, which
> is only necessary if we allow L1 and L2 to differ.  That would
> be a pathology IMO, not a use case.
>
> The way I visualize this is that each newly arrived class
> checks in with its host.  If the name is on the list, it gets in.
>
> Sound good?

This is basically what the existing validation logic does - modulo the 
order of operations:

1. load "H" using C's classloader
2. H contains an attribute of the form NestMembers({... "C", ...})
3. Check is_same_package(C, H)

The order can be changed if that is significant.

David
-----

> — John