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

[mandy chung]

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.

Nit:

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


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

Mandy