[Nestmates] RFR: 8197539: [Nestmates] Revert all changes to VerifyAccess.isSameMemberPackage and Lookup.in behaviour
david.holmes at oracle.com
Tue Feb 13 21:50:42 UTC 2018
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:
>> 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.
More information about the valhalla-dev