[Nestmates] RFR: 8196320: [Nestmates] Restore the old enclosing-class based isSamePackageMember check in sun/invoke/util/VerifyAccess.java

mandy chung mandy.chung at oracle.com
Wed Jan 31 19:13:56 UTC 2018

On 1/30/18 8:54 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196320
> webrev: http://cr.openjdk.java.net/~dholmes/8196320/webrev/
> I've restored the original enclosing-class check and the 
> isSamePackageMember method, but renamed it to areNestMates. It will 
> first do the real Reflection.areNestMates check, and if that fails 
> fall-back to the pre-nestmate enclosing class check.

Does core reflection work with the pre-nestmate class scenario?

Should JVM_AreNestMates handle the pre-nestmate class and return true if 
they are the same class or same runtime package?

> I've added a test under runtime/Nestmates/legacy (where I'll 
> accumulate tests that check legacy code still works after the nestmate 
> changes - for specific areas like this.) 

At some point we should look at where the nestmates tests should be 
placed.  For example, this test seems to be appropriate to land in 
test/jdk/java/lang/invoke.   Just a note to consider when integrating 
this to jdk.

> The test will need tweaking once we bump the version to 11 
> (unfortunately there's no system property that reports the classfile 
> version AFAICS).

Are you referring to this check:

   39     static boolean VMHasNestmates =
   40         System.getProperty("java.vm.specification.version").equals("10");
   84         if (!VMHasNestmates) {
   85             throw new Error("This test is only for JDK 11 with nestmates");
   86         }

If so, I don't think you need this check.  This test uses Class::getNestHost
method that will fail to compile if running on an older JDK.


   30  * @compile -source 10 -target 10 TestPrivateLookup.java

Alternatively it can use --release 10 instead of -source and -target.


More information about the valhalla-dev mailing list