Nestmate same-package check

David Holmes david.holmes at
Thu Apr 20 03:24:26 UTC 2017

On 20/04/2017 12:42 PM, John Rose wrote:
> On Apr 18, 2017, at 11:42 AM, Dan Smith <daniel.smith at
> <mailto:daniel.smith at>> wrote:
>> I've uploaded a draft of JVMS changes for JEP 181 "Align JVM Checks
>> with Java Language Rules for Nested Classes" to:
>> 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.


> — John

More information about the valhalla-spec-observers mailing list