Here's the original code checking private access in VerifyAccess.isMemberAccessible:

 case PRIVATE:
     // Loosened rules for privates follows access rules for inner classes.
     return (ALLOW_NESTMATE_ACCESS &&
            (allowedModes & PRIVATE) != 0 &&
             isSamePackageMember(defc, lookupClass));

ALLOW_NESTMATE_ACCESS was always false as it's an experimental field. So for private access the above will always return false - both for nestmate classfile versions and earlier. In short no nestmate access allowed when defc and lookupClass are distinct. (Lookup.in handles the defc==lookupClass case and that is checked earlier.)

For nestmates I modified the above to be:

 case PRIVATE:
     // Loosened rules for privates follows access rules for inner classes.
     return ((allowedModes & PRIVATE) != 0 &&
             isSamePackageMember(defc, lookupClass));

where isSamePackageMember() only did Reflection.areNestMates(). So this could return true for nestmate classfiles, but always false for older classfiles. Which was exactly what we wanted.

With the fix for JDK-8196320 however, isSamePackageMember() (now renamed to areNestMates) first checks Reflection.areNestMates() and then if that is false, the old enclosing-class check. Consequently the check can now return true for both nestmate classfiles and earlier classfiles! That is wrong.

To fix this we replace the call to VerifyAccess.areNestMates() with Reflection.areNestMates();

There is also a temporary psuedo-assertion verifying that if we've granted private nestmate access then refc==defc (which should be assured by the resolution of the member being accessed).