27  * The {@code java.lang.invoke} package contains dynamic language support provided directly by
  28  * the Java core class libraries and virtual machine.
  29  *
  30  * <p>
  31  * As described in the Java Virtual Machine Specification,
  32  * certain types in this package have special relations to dynamic
  33  * language support in the virtual machine:
  34  * <ul>
  35  * <li>The classes {@link java.lang.invoke.MethodHandle MethodHandle}
  36  * {@link java.lang.invoke.VarHandle VarHandle} contain
  37  * <a href="MethodHandle.html#sigpoly">signature polymorphic methods</a>
  38  * which can be linked regardless of their type descriptor.
  39  * Normally, method linkage requires exact matching of type descriptors.
  40  * </li>
  41  *
  42  * <li>The JVM bytecode format supports immediate constants of
  43  * the classes {@link java.lang.invoke.MethodHandle MethodHandle} and {@link java.lang.invoke.MethodType MethodType}.
  44  * </li>
  45  * </ul>
  46  *
  47  * <h1><a name="jvm_mods"></a>Summary of relevant Java Virtual Machine changes</h1>
  48  * The following low-level information summarizes relevant parts of the
  49  * Java Virtual Machine specification.  For full details, please see the
  50  * current version of that specification.
  51  *
  52  * Each occurrence of an {@code invokedynamic} instruction is called a <em>dynamic call site</em>.
  53  * <h2><a name="indyinsn"></a>{@code invokedynamic} instructions</h2>
  54  * A dynamic call site is originally in an unlinked state.  In this state, there is
  55  * no target method for the call site to invoke.
  56  * <p>
  57  * Before the JVM can execute a dynamic call site (an {@code invokedynamic} instruction),
  58  * the call site must first be <em>linked</em>.
  59  * Linking is accomplished by calling a <em>bootstrap method</em>
  60  * which is given the static information content of the call site,
  61  * and which must produce a {@link java.lang.invoke.MethodHandle method handle}
  62  * that gives the behavior of the call site.
  63  * <p>
  64  * Each {@code invokedynamic} instruction statically specifies its own
  65  * bootstrap method as a constant pool reference.
  66  * The constant pool reference also specifies the call site's name and type descriptor,
  67  * just like {@code invokevirtual} and the other invoke instructions.
  68  * <p>
  69  * Linking starts with resolving the constant pool entry for the
  70  * bootstrap method, and resolving a {@link java.lang.invoke.MethodType MethodType} object for
  71  * the type descriptor of the dynamic call site.
  72  * This resolution process may trigger class loading.
  73  * It may therefore throw an error if a class fails to load.

  27  * The {@code java.lang.invoke} package contains dynamic language support provided directly by
  28  * the Java core class libraries and virtual machine.
  29  *
  30  * <p>
  31  * As described in the Java Virtual Machine Specification,
  32  * certain types in this package have special relations to dynamic
  33  * language support in the virtual machine:
  34  * <ul>
  35  * <li>The classes {@link java.lang.invoke.MethodHandle MethodHandle}
  36  * {@link java.lang.invoke.VarHandle VarHandle} contain
  37  * <a href="MethodHandle.html#sigpoly">signature polymorphic methods</a>
  38  * which can be linked regardless of their type descriptor.
  39  * Normally, method linkage requires exact matching of type descriptors.
  40  * </li>
  41  *
  42  * <li>The JVM bytecode format supports immediate constants of
  43  * the classes {@link java.lang.invoke.MethodHandle MethodHandle} and {@link java.lang.invoke.MethodType MethodType}.
  44  * </li>
  45  * </ul>
  46  *
  47  * <h1><a id="jvm_mods"></a>Summary of relevant Java Virtual Machine changes</h1>
  48  * The following low-level information summarizes relevant parts of the
  49  * Java Virtual Machine specification.  For full details, please see the
  50  * current version of that specification.
  51  *
  52  * Each occurrence of an {@code invokedynamic} instruction is called a <em>dynamic call site</em>.
  53  * <h2><a id="indyinsn"></a>{@code invokedynamic} instructions</h2>
  54  * A dynamic call site is originally in an unlinked state.  In this state, there is
  55  * no target method for the call site to invoke.
  56  * <p>
  57  * Before the JVM can execute a dynamic call site (an {@code invokedynamic} instruction),
  58  * the call site must first be <em>linked</em>.
  59  * Linking is accomplished by calling a <em>bootstrap method</em>
  60  * which is given the static information content of the call site,
  61  * and which must produce a {@link java.lang.invoke.MethodHandle method handle}
  62  * that gives the behavior of the call site.
  63  * <p>
  64  * Each {@code invokedynamic} instruction statically specifies its own
  65  * bootstrap method as a constant pool reference.
  66  * The constant pool reference also specifies the call site's name and type descriptor,
  67  * just like {@code invokevirtual} and the other invoke instructions.
  68  * <p>
  69  * Linking starts with resolving the constant pool entry for the
  70  * bootstrap method, and resolving a {@link java.lang.invoke.MethodType MethodType} object for
  71  * the type descriptor of the dynamic call site.
  72  * This resolution process may trigger class loading.
  73  * It may therefore throw an error if a class fails to load.