[Nestmates] RFR: 8197539: [Nestmates] Revert all changes to VerifyAccess.isSameMemberPackage and Lookup.in behaviour (original) (raw)
mandy chung mandy.chung at oracle.com
Tue Feb 13 21:10:10 UTC 2018
- Previous message (by thread): [Nestmates] RFR: 8197539: [Nestmates] Revert all changes to VerifyAccess.isSameMemberPackage and Lookup.in behaviour
- Next message (by thread): [Nestmates] RFR: 8197539: [Nestmates] Revert all changes to VerifyAccess.isSameMemberPackage and Lookup.in behaviour
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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))
Mandy
- Previous message (by thread): [Nestmates] RFR: 8197539: [Nestmates] Revert all changes to VerifyAccess.isSameMemberPackage and Lookup.in behaviour
- Next message (by thread): [Nestmates] RFR: 8197539: [Nestmates] Revert all changes to VerifyAccess.isSameMemberPackage and Lookup.in behaviour
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]