[Nestmates] RFR: 8197539: [Nestmates] Revert all changes to VerifyAccess.isSameMemberPackage and Lookup.in behaviour (original) (raw)

David Holmes david.holmes at oracle.com
Tue Feb 13 21:50:42 UTC 2018

Hi Mandy,

Thanks for looking at this.

On 14/02/2018 7:10 AM, mandy chung wrote:

On 2/11/18 7:32 PM, David Holmes wrote:

webrev: http://cr.openjdk.java.net/~dholmes/8197539/webrev/

webrev relative to mainline: http://cr.openjdk.java.net/~dholmes/8197539/webrev.mainline/ bug: https://bugs.openjdk.java.net/browse/JDK-8197539 After going through the issue in JDK-8197395, there is no need to change VerifyAccess.isSameMemberPackage to be aware of nestmates, as nestmates will already pass the enclosing class check. So we can restore this code to its existing mainline form. That's right.  It'd be good to add a comment to indicate that this captures both legacy and nestmate case. 359 if (getOutermostEnclosingClass(class1) != getOutermostEnclosingClass(class2))

I would prefer to leave unmodified code completely unmodified to simplify the eventual code review when pushing to mainline. While such a comment may seem useful due to the way this issue arose, if we back up and view this as never-changed code, then commenting that it doesn't need to change seems unnecessary to me. There are numerous things that work unchanged with nestmates (specifically anything to do with inner classes attributes and existing enclosing class notions), and we won't want to add comments to them all.

Thanks, David

Mandy

More information about the valhalla-dev mailing list