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

*** 316,326 ****
       * <h2><a id="lookups"></a>Lookup Factory Methods</h2>
       * The factory methods on a {@code Lookup} object correspond to all major
       * use cases for methods, constructors, and fields.
       * Each method handle created by a factory method is the functional
       * equivalent of a particular <em>bytecode behavior</em>.
!      * (Bytecode behaviors are described in section 5.4.3.5 of the Java Virtual Machine Specification.)
       * Here is a summary of the correspondence between these factory methods and
       * the behavior of the resulting method handles:
       * <table class="striped">
       * <caption style="display:none">lookup method behaviors</caption>
       * <thead>
--- 316,326 ----
       * <h2><a id="lookups"></a>Lookup Factory Methods</h2>
       * The factory methods on a {@code Lookup} object correspond to all major
       * use cases for methods, constructors, and fields.
       * Each method handle created by a factory method is the functional
       * equivalent of a particular <em>bytecode behavior</em>.
!      * (Bytecode behaviors are described in section {@jvms 5.4.3.5} of the Java Virtual Machine Specification.)
       * Here is a summary of the correspondence between these factory methods and
       * the behavior of the resulting method handles:
       * <table class="striped">
       * <caption style="display:none">lookup method behaviors</caption>
       * <thead>
*** 500,510 ****
       * independently of any {@code Lookup} object.
       * <p>
       * If the desired member is {@code protected}, the usual JVM rules apply,
       * including the requirement that the lookup class must either be in the
       * same package as the desired member, or must inherit that member.
!      * (See the Java Virtual Machine Specification, sections 4.9.2, 5.4.3.5, and 6.4.)
       * In addition, if the desired member is a non-static field or method
       * in a different package, the resulting method handle may only be applied
       * to objects of the lookup class or one of its subclasses.
       * This requirement is enforced by narrowing the type of the leading
       * {@code this} parameter from {@code C}
--- 500,510 ----
       * independently of any {@code Lookup} object.
       * <p>
       * If the desired member is {@code protected}, the usual JVM rules apply,
       * including the requirement that the lookup class must either be in the
       * same package as the desired member, or must inherit that member.
!      * (See the Java Virtual Machine Specification, sections {@jvms 4.9.2}, {@jvms 5.4.3.5}, and {@jvms 6.4}.)
       * In addition, if the desired member is a non-static field or method
       * in a different package, the resulting method handle may only be applied
       * to objects of the lookup class or one of its subclasses.
       * This requirement is enforced by narrowing the type of the leading
       * {@code this} parameter from {@code C}
*** 513,533 ****
       * <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 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.
       * A lookup of such an internal method will produce a {@code NoSuchMethodException}.
       * <p>
       * If the relationship between nested types is expressed directly through the
       * {@code NestHost} and {@code NestMembers} attributes
!      * (see the Java Virtual Machine Specification, sections 4.7.28 and 4.7.29),
       * then the associated {@code Lookup} object provides direct access to
       * the lookup class and all of its nestmates
       * (see {@link java.lang.Class#getNestHost Class.getNestHost}).
       * Otherwise, access between nested classes is obtained by the Java compiler creating
       * a wrapper method to access a private method of another class in the same nest.
--- 513,533 ----
       * <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}.)
       * <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.
       * A lookup of such an internal method will produce a {@code NoSuchMethodException}.
       * <p>
       * If the relationship between nested types is expressed directly through the
       * {@code NestHost} and {@code NestMembers} attributes
!      * (see the Java Virtual Machine Specification, sections {@jvms 4.7.28} and {@jvms 4.7.29}),
       * then the associated {@code Lookup} object provides direct access to
       * the lookup class and all of its nestmates
       * (see {@link java.lang.Class#getNestHost Class.getNestHost}).
       * Otherwise, access between nested classes is obtained by the Java compiler creating
       * a wrapper method to access a private method of another class in the same nest.