src/java.base/share/classes/java/lang/invoke/MethodHandles.java

rev 58565 : 8238358: Implementation of JEP 371: Hidden Classes
Reviewed-by: duke
Contributed-by: mandy.chung@oracle.com, lois.foltan@oracle.com, david.holmes@oracle.com, harold.seigel@oracle.com, serguei.spitsyn@oracle.com, alex.buckley@oracle.com, jamsheed.c.m@oracle.com
rev 58566 : [mq]: hidden-class-3-detla
rev 58567 : [mq]: rename-isHidden
rev 58568 : [mq]: hidden-class-3-jdarcy

@@ -571,11 +571,11 @@
      * <p>
      * The JVM imposes a similar requirement on {@code invokespecial} instruction,
      * that the receiver argument must match both the resolved method <em>and</em>
      * the current class.  Again, this requirement is enforced by narrowing the
      * type of the leading parameter to the resulting method handle.
-     * (See the Java Virtual Machine Specification, section {@jmvs 4.10.1.9}.)
+     * (See the Java Virtual Machine Specification, section {@jvms 4.10.1.9}.)
      * <p>
      * The JVM represents constructors and static initializer blocks as internal methods
      * with special names ({@code "<init>"} and {@code "<clinit>"}).
      * The internal syntax of invocation instructions allows them to refer to such internal
      * methods as if they were normal methods, but the JVM bytecode verifier rejects them.

@@ -1791,35 +1791,35 @@
          * refers to the new {@code CONSTANT_Utf8_info} structure.
          *
          * <p> Let {@code L} be the defining class loader of the lookup class of this {@code Lookup}.
          *
          * <p> {@code C} is derived with name {@code CN}, class loader {@code L}, and
-         * purported representation {@code newBytes} as if by the rules of JVMS 5.3.5,
+         * purported representation {@code newBytes} as if by the rules of JVMS {@jvms 5.3.5},
          * with the following adjustments:
          * <ul>
          * <li> The constant indicated by {@code this_class} is permitted to specify a name
          * that includes a single {@code "."} character, even though this is not a valid
          * binary class or interface name in internal form.</li>
          *
          * <li> The Java Virtual Machine marks {@code L} as the defining class loader of {@code C},
          * but no class loader is recorded as an initiating class loader of {@code C}.</li>
          *
-         * <li> {@code C} is considered to have the same runtime package and
-         * {@linkplain java.security.ProtectionDomain protection domain}
+         * <li> {@code C} is considered to have the same runtime
+         * {@linkplain Class#getPackage() package}, {@linkplain Class#getModule() module}
+         * and {@linkplain java.security.ProtectionDomain protection domain}
          * as the lookup class of this {@code Lookup}.
-         *
          * <li> Let {@code GN} be the binary name obtained by taking {@code N}
          * (a binary name encoded in internal form) and replacing ASCII forward slashes with
          * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C},
          * {@link Class#getName()} returns the string {@code GN + "/" + <suffix>}, even though
          * this is not a valid binary class or interface name.</li>
          * </ul>
          * </li>
          * </ol>
          *
          * <p> After {@code C} is derived, it is linked by the Java Virtual Machine.
-         * Linkage occurs as specified in JVMS 5.4.3, with the following adjustments:
+         * Linkage occurs as specified in JVMS {@jvms 5.4.3}, with the following adjustments:
          * <ul>
          * <li> During verification, whenever it is necessary to load the class named
          * {@code CN}, the attempt succeeds, producing class {@code C}. No request is
          * made of any class loader.</li>
          *

@@ -1879,12 +1879,12 @@
          * In contrast, if {@code STRONG} is used, then the JVM may run out of memory,
          * just as if normal classes were created by class loaders.
          *
          * <p> Classes and interfaces in a nest are allowed to have mutual access to
          * their private members.  The nest relationship is determined by
-         * the {@code NestHost} attribute (JVMS 4.7.28) and
-         * the {@code NestMembers} attribute (JVMS 4.7.29) in a {@code class} file.
+         * the {@code NestHost} attribute (JVMS {@jvms 4.7.28}) and
+         * the {@code NestMembers} attribute (JVMS {@jvms 4.7.29}) in a {@code class} file.
          * By default, a hidden class belongs to a nest consisting only of itself
          * because a hidden class has no binary name.
          * The {@link ClassOption#NESTMATE NESTMATE} option can be passed in {@code options}
          * to create a hidden class or interface {@code C} as a member of a nest.
          * The nest to which {@code C} belongs is not based on any {@code NestHost} attribute

@@ -1892,11 +1892,11 @@
          * Instead, the following rules determine the nest host of {@code C}:
          * <ul>
          * <li>If the nest host of the lookup class of this {@code Lookup} has previously
          *     been determined, then let {@code H} be the nest host of the lookup class.
          *     Otherwise, the nest host of the lookup class is determined using the
-         *     algorithm in JVMS 5.4.4, yielding {@code H}.</li>
+         *     algorithm in JVMS {@jvms 5.4.4}, yielding {@code H}.</li>
          * <li>The nest host of {@code C} is determined to be {@code H},
          *     the nest host of the lookup class.</li>
          * </ul>
          *
          * <p> A hidden class or interface may be serializable, but this requires a custom