diff --git a/index.md b/index.md
--- a/index.md
+++ b/index.md
@@ -375,20 +375,23 @@
4.4.8. The CONSTANT_MethodHandle_info Structure
4.4.9. The CONSTANT_MethodType_info Structure
4.4.10. The CONSTANT_InvokeDynamic_info Structure
4.4.9917. The CONSTANT_ConstantDynamic_info Structure
4.5. Fields
4.6. Methods

4.7. Attributes

@@ -1443,20 +1446,21 @@

<!– link reference definition [4.4.9917. The CONSTANT_ConstantDynamic_info Structure]: jvms-4.html#jvms-4.4.9917 –>

diff --git a/jvms-4.md b/jvms-4.md
--- a/jvms-4.md
+++ b/jvms-4.md
@@ -113,20 +113,23 @@
4.4.8. The CONSTANT_MethodHandle_info Structure
4.4.9. The CONSTANT_MethodType_info Structure
4.4.10. The CONSTANT_InvokeDynamic_info Structure
4.4.9917. The CONSTANT_ConstantDynamic_info Structure
4.5. Fields
4.6. Methods

4.7. Attributes

@@ -1613,20 +1616,21 @@

CONSTANT_String 8 CONSTANT_Integer 3 CONSTANT_Float 4 CONSTANT_Long 5 CONSTANT_Double 6 CONSTANT_NameAndType 12 CONSTANT_Utf8 1 CONSTANT_MethodHandle 15 CONSTANT_MethodType 16 CONSTANT_InvokeDynamic 18 CONSTANT_ConstantDynamic 17


@@ -2648,20 +2652,87 @@

CONSTANT_NameAndType_info structure (§4.4.6) representing a method name and method descriptor (§4.3.3).

4.4.9917. The CONSTANT_ConstantDynamic_info Structure

The CONSTANT_ConstantDynamic_info structure introduces a dynamic constant specifier into the constant pool, which when resolved can produce an arbitrary, user-programmable dynamic constant. In a manner closely parallel to the CONSTANT_InvokeDynamic_info structure (§4.4.10), this structure specifies a bootstrap method, the dynamic constant invocation name, the type of the dynamic constant, and optionally, a sequence of additional constants called static arguments to the bootstrap method.
+CONSTANT_ConstantDynamic_info {
+    u1 tag;
+    u2 bootstrap_method_attr_index;
+    u2 name_and_type_index;
+}
The items of the CONSTANT_ConstantDynamic_info structure are as follows:
tag

 
The tag item of the CONSTANT_ConstantDynamic_info structure has the value CONSTANT_ConstantDynamic (17).

bootstrap_method_attr_index

 
The value of the bootstrap_method_attr_index item must be a valid index into the bootstrap_methods array of the bootstrap method table ([§4.7.23]) of this class file.

name_and_type_index

 
The value of the name_and_type_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_NameAndType_info structure (§4.4.6) representing a field name and field descriptor (§4.3.2).

4.5. Fields

@@ -7958,27 +8029,29 @@

The BootstrapMethods attribute is a variable-length attribute in the attributes table of a ClassFile structure ([§4.1]). The BootstrapMethods attribute records bootstrap method specifiers referenced by invokedynamic instructions (§invokedynamic). (§invokedynamic) and dynamic constants (§4.4.9917).

There must be exactly one BootstrapMethods attribute in the attributes table of a ClassFile structure if the constant_pool table of the ClassFile structure has at least one CONSTANT_InvokeDynamic_info entry (§4.4.10). (§4.4.10) or CONSTANT_ConstantDynamic_info entry (§4.4.9917).

There may be at most one BootstrapMethods attribute in the attributes table of a ClassFile structure.

The BootstrapMethods attribute has the following format:

@@ -8050,46 +8123,58 @@

driven by the continuing resolution of the call site specifier in §invokedynamic, where execution of invoke in java.lang.invoke.MethodHandle requires that the bootstrap method handle be adjustable to the actual arguments being passed, as if by a call to java.lang.invoke.MethodHandle.asType. Accordingly, the reference_kind item of the CONSTANT_MethodHandle_info structure should have the value 6 or 8 ([§5.4.3.5]), and the reference_index item should specify a static method or constructor that takes three arguments will accept a leading argument of type java.lang.invoke.MethodHandles.Lookup, String, and java.lang.invoke.MethodType, in that order. either two or more arguments beginning with a String and a java.lang.invoke.MethodType or a java.lang.Class and then followed by all the static arguments, or else only a second argument of type java.lang.invoke.BootstrapCallInfo.

The call to the bootstrap method must return normally and produce either an object of type java.lang.invoke.CallSite (if this entry is used by a CONSTANT_InvokeDynamic_info entry) or an object of the associated field type (if this entry is used by a CONSTANT_ConstantDynamic_info entry).

Otherwise, invocation of the bootstrap method handle during call site specifier resolution will complete abruptly.

num_bootstrap_arguments
The value of the num_bootstrap_arguments item gives the number of items in the bootstrap_arguments array.

bootstrap_arguments[]
Each entry in the bootstrap_arguments array must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_String_info, CONSTANT_Class_info, CONSTANT_Integer_info, CONSTANT_Long_info, CONSTANT_Float_info, CONSTANT_Double_info, CONSTANT_ConstantDynamic_info, CONSTANT_MethodHandle_info, or CONSTANT_MethodType_info structure (§4.4.3, §4.4.1, §4.4.4, §4.4.5, §4.4.9917, §4.4.8, §4.4.9).

@@ -9782,20 +9867,29 @@

For clarity, we assume that field and method descriptors (§4.3.2, §4.3.3) are mapped into more readable names: the leading L and trailing ; are dropped from class names, and the BaseType characters used for primitive types are mapped to the names of those types.

For example, a getfield instruction whose operand

@@ -14757,40 +14851,56 @@

An ldc instruction with operand CP is type safe iff CP refers to a constant pool entry denoting an entity of type Type, where Type is either int, float, String, Class, java.lang.invoke.MethodType, or java.lang.invoke.MethodHandle, and one can validly push Type onto the incoming operand stack yielding the outgoing type state.

An ldc_w instruction is type safe iff

state, or if the equivalent ldc instruction constant_pool entry at that index is type safe. a CONSTANT_ConstantDynamic_info structure whose CONSTANT_NameAndType_info structure refers to a field type that can be validly pushed onto the incoming operand stack yielding the outgoing type state.

 instructionIsTypeSafe(ldc(CP), Environment, _Offset, StackFrame,
                       NextStackFrame, ExceptionStackFrame) :- 
     functor(CP, Tag, _),
     isBootstrapLoader(BL),
     member([Tag, Type], [
         [int, int],
         [float, float],
         [string, class('java/lang/String', BL)],
         [classConst, class('java/lang/Class', BL)],
         [methodTypeConst, class('java/lang/invoke/MethodType', BL)],
         [methodHandleConst, class('java/lang/invoke/MethodHandle', BL)],
     ]),
     validTypeTransition(Environment, [], Type, StackFrame, NextStackFrame),
     exceptionStackFrame(StackFrame, ExceptionStackFrame).

+instructionIsTypeSafe(ldc(CP), Environment, _Offset, StackFrame,
+                      NextStackFrame, ExceptionStackFrame) :- 
+    CP = dconstant(_ConstantName, FieldDescriptor),
+    parseFieldDescriptor(FieldDescriptor, FieldType),
+    validTypeTransition(Environment, [], FieldType,
+                        StackFrame, NextStackFrame),
+    exceptionStackFrame(StackFrame, ExceptionStackFrame).

An ldc_w instruction is type safe iff the equivalent ldc instruction is type safe.

 instructionHasEquivalentTypeRule(ldc_w(CP), ldc(CP))

@@ -16677,20 +16787,21 @@

<!– link reference definition [4.4.9917. The CONSTANT_ConstantDynamic_info Structure]: jvms-4.html#jvms-4.4.9917 –>

@@ -16948,20 +17059,21 @@

<!– link reference definition [§4.4.9917]: jvms-4.html#jvms-4.4.9917 “4.4.9917. The CONSTANT_ConstantDynamic_info Structure”{.xref} –>

diff --git a/jvms-5.md b/jvms-5.md
--- a/jvms-5.md
+++ b/jvms-5.md
@@ -106,21 +106,21 @@
5.4.3.3. Method Resolution
5.4.3.4. Interface Method Resolution
5.4.3.5. Method Type and Method Handle Resolution
[5.4.3.6. Call Site Bootstrap Specifier Resolution]
5.4.4. Access Control
5.4.5. Overriding
@@ -266,40 +266,51 @@

In addition, certain run-time values which are not symbolic references are derived from items found in the constant_pool table:

@@ -364,22 +375,22 @@
The remaining structures in the constant_pool table of the binary representation of a class or interface - the CONSTANT_NameAndType_info and CONSTANT_Utf8_info structures (§4.4.6, §4.4.7) - are only used indirectly when deriving symbolic references to classes, interfaces, methods, fields, method types, and method handles, and when deriving string literals and call site bootstrap

specifiers.

@@ -1197,42 +1208,50 @@

reference.

If an attempt by the Java Virtual Machine to resolve a symbolic reference fails because an error is thrown that is an instance of LinkageError (or a subclass), then subsequent attempts to resolve the reference always fail with the same error that was thrown as a result of the initial resolution attempt.

A symbolic reference to a call site bootstrap specifier by a specific invokedynamic instruction must not be resolved prior to execution of that instruction.

A symbolic reference to a bootstrap specifier by a CONSTANT_ConstantDynamic_info constant must not be resolved prior to resolution of that constant.

In the case of failed resolution of an invokedynamic instruction, the bootstrap method is not re-executed on subsequent resolution attempts.

In the case of failed resolution of a CONSTANT_ConstantDynamic_info constant, the bootstrap method is not re-executed on subsequent resolution attempts.

Certain of the instructions above require additional linking checks when resolving symbolic references. For instance, in order for a getfield instruction to successfully resolve the symbolic reference to the field on which it operates, it must not only complete the field resolution steps given in [§5.4.3.2] but also check that the field is not static. If it is a static field, a linking exception must be thrown.

Notably, in order for an invokedynamic instruction to successfully resolve the symbolic reference to a call site bootstrap specifier, the bootstrap method specified therein must complete normally and return a suitable call site bootstrap object. If the bootstrap method completes abruptly or returns an unsuitable call site object, result, a linking exception must be thrown.

Linking exceptions generated by checks that are specific to the execution of a particular Java Virtual Machine instruction are given in the description of that instruction and are not covered in this general discussion of resolution. Note that such exceptions, although described as part of the execution of Java Virtual Machine instructions rather than resolution, are still properly considered failures of resolution.

@@ -1927,92 +1946,134 @@

bytecode behavior. Their behavior is defined by the method of java.lang.invoke.MethodHandles that creates them. For example, a method handle may, when invoked, first apply transformations to its argument values, then supply the transformed values to the invocation of another method handle, then apply a transformation to the value returned from that invocation, then return the transformed value as its own result.

<div class=“section” title=“5.4.3.6. Call Site title=”5.4.3.6. Bootstrap Specifier Resolution“>

5.4.3.6. Call Site 5.4.3.6. Bootstrap Specifier Resolution

To resolve an unresolved symbolic reference to a call site bootstrap specifier involves three steps:

  • A call site bootstrap specifier gives a symbolic reference to a method handle which is to serve as the bootstrap method for a dynamic call site ([§4.7.23]). ([§4.7.23]) or dynamic constant. The method handle is resolved to obtain a reference to an instance of java.lang.invoke.MethodHandle ([§5.4.3.5]).

  • A call site specifier gives a

    If the bootstrap method descriptor, TD. A reference to has an instance arity of java.lang.invoke.MethodType is obtained as two or less, and if by resolution of a symbolic reference to it is not a variable-arity method type with handle, then the same parameter type and return types as TD ([§5.4.3.5]).

  • A call site specifier gives zero or more [*static arguments*]{.emphasis}, which communicate application-specific metadata to the bootstrap method. Any

    static arguments which are symbolic references to classes, method handles, or method types not resolved immediately. The remaining steps for resolving these data are resolved, as if deferred until their values are explicitly requested by invocation the execution of the ldc instruction bootstrap method. Instead of being invoked on these data, the bootstrap method will be invoked on an instance of java.lang.invoke.BootstrapCallInfo, an object whose methods provide the necessary callbacks to query the resolved components of the bootstrap specifier. This case is called lazy resolution of the bootstrap specifier. For higher arity or non-varargs bootstrap methods, an eager resolution of the bootstrap specifier resolves all of the component constants and presents them immediately as arguments to the bootstrap method, as described below.

  • A bootstrap specifier gives a method or field descriptor, TD. A reference to an instance of java.lang.Class (for a field descriptor) or java.lang.invoke.MethodType (for a method descriptor) is obtained as if by resolution of a symbolic reference to a method type with the same parameter and return types as TD ([§5.4.3.5]). In the case of a field descriptor, the field descriptor is regarded as if it were the sole parameter of the method descriptor to be resolved, and the sole class reference is extracted as if by MethodType::parameterType.
  • A bootstrap specifier gives zero or more [*static arguments*]{.emphasis}, which communicate application-specific metadata to the bootstrap method. Any static arguments which are symbolic references to classes, method handles, method types, or dynamic constants are resolved, as if by invocation of the ldc instruction

    ([§ldc]), to obtain references to Class objects, java.lang.invoke.MethodHandle objects, and java.lang.invoke.MethodType objects respectively. Any static arguments that are string literals are used to obtain references to String objects.

The result of call site eagerly resolving a bootstrap specifier resolution is a tuple consisting of:

  • the reference to an instance of java.lang.invoke.MethodHandle,

  • the reference to an instance of java.lang.Class or java.lang.invoke.MethodType,

  • the references to instances of Class, java.lang.invoke.MethodHandle, java.lang.invoke.MethodType, String, and String. any values resolved from dynamic constant specifiers.

The result of lazily resolving a bootstrap specifier is a tuple consisting of:
  • the reference to an instance of java.lang.invoke.MethodHandle,
  • the reference to an instance of java.lang.invoke.BootstrapCallInfo.

During resolution of the symbolic reference to the method handle in the call site bootstrap specifier, or resolution of the symbolic reference to the method type for the method descriptor or the class type for the field descriptor in the call site bootstrap specifier, or resolution of a symbolic reference to any static argument, any of the exceptions pertaining to method type or method handle resolution may be thrown ([§5.4.3.5]).

@@ -2185,21 +2246,21 @@
  • The first invocation of a java.lang.invoke.MethodHandle instance which was the result of method handle resolution ([§5.4.3.5]) for a method handle of kind 2 (REF_getStatic), 4 (REF_putStatic), 6 (REF_invokeStatic), or 8 (REF_newInvokeSpecial).

    This implies that the class of a bootstrap method is initialized when the bootstrap method is invoked for an invokedynamic instruction (§invokedynamic), as part of the continuing resolution of the call site bootstrap specifier.

  • Invocation of certain reflective methods in the class library (§2.12), for example, in class Class or in package java.lang.reflect.

  • If C is a class, the initialization of one of its subclasses.

@@ -2469,21 +2530,21 @@

<!– link reference definition [5.4.3.6. Call Site Bootstrap Specifier Resolution]: jvms-5.html#jvms-5.4.3.6 –>

@@ -2493,20 +2554,21 @@

<!– link reference definition [§4.4.9917]: jvms-4.html#jvms-4.4.9917 “4.4.9917. The CONSTANT_ConstantDynamic_info Structure”{.xref} –>

diff --git a/jvms-6.md b/jvms-6.md
--- a/jvms-6.md
+++ b/jvms-6.md
@@ -15197,126 +15197,185 @@

site specifier (§5.1). The values of the third and fourth operand bytes must always be zero.

The call site specifier is resolved ([§5.4.3.6]) for this specific dynamic call site to obtain a reference to a java.lang.invoke.MethodHandle instance that will serve as the bootstrap method, a reference to a java.lang.invoke.MethodType instance, and references to static arguments.

Next, as part of the continuing resolution of the call site (Note: When a bootstrap method is used to resolve a dynamic call site, it is invoked once per distinct call site. When a bootstrap method is used to resolve a dynamic constant, it is called only once per CONSTANT_ConstantDynamic_info structure in the constant pool, not once per instruction which may use this constant.) Next, as part of the continuing resolution of the call site

specifier, the bootstrap method is invoked as if by execution of an invokevirtual instruction ([§invokevirtual]) that contains a run-time constant pool index to a symbolic reference R where:

  • R is a symbolic reference to a method of a class (§5.1);

  • for the symbolic reference to the class in which the method is to be found, R specifies java.lang.invoke.MethodHandle;

  • for the name of the method, R specifies invoke; invokeWithArguments;

  • for the descriptor of the method, R specifies a return type of java.lang.invoke.CallSite and parameter types derived from the items pushed on the operand stack. java.lang.Object.

    The first three parameter types are java.lang.invoke.MethodHandles.Lookup, String, and java.lang.invoke.MethodType, in that order. If the call site specifier has any static arguments, then a sole parameter type for each argument is appended to the parameter types an array of the method descriptor in the order that the java.lang.Object references. (All arguments were pushed on to the operand stack. These parameter types may will be Class, java.lang.invoke.MethodHandle, java.lang.invoke.MethodType, String, int, long, float, or double. collected into this array, as if by variable arity invocation.)

and where it is as if the following items were pushed, in order, on the operand stack:

  • the reference to the java.lang.invoke.MethodHandle object for the bootstrap method;

  • a reference to a fresh array of java.lang.Object references of length 2 (if the bootstrap method accepts exactly two arguments and is not of variable arity) or of length three more than the number of static arguments.

and where the array is initialized with the following values, in order:
  • a reference to a

    java.lang.invoke.MethodHandles.Lookup object for the class in which this dynamic call site occurs;

  • if the array is of length two, a reference to an instance of the interface java.lang.invoke.BootstrapCallInfo which describes this bootstrap method and its arguments;

  • if the array is of length three or more,

    a reference to the String for the method name in the call site specifier;

  • if the array is of length three or more, the reference to the java.lang.invoke.MethodType object obtained for the method descriptor in the call site specifier;

  • if the array is of length three or more, the resolved references to classes, method types, method handles, and string literals denoted as static arguments in the call site specifier, and numeric all values ([§2.3.1], [§2.3.2]) denoted as static arguments in the call site specifier, in the order in which they appear in the call site specifier. (That is, no boxing occurs (Boxing is performed for primitive values.)

(Note: When a bootstrap method is used to resolve a dynamic call site, it is given a java.lang.invoke.MethodType object to represent the required invocation type of the call site. When a bootstrap method is used to resolve a dynamic constant, it is given a java.lang.Class object to represent the required field type of the constant. Likewise, the string constant passed to the bootstrap method is a field name instead of a method name, in the case of a dynamic constant.) Despite the apparent demand for boxing and argument array formation, the Java Virtual Machine is permitted to implement the call to the bootstrap method in any way that delivers the values which the bootstrap method requires, avoiding boxing and array formation if needed. The semantics of method handle invocation are such that the invokeWithArguments call is almost always equivalent to an invoke call which more accurately preserves the actual types of the arguments. The use of invokeWithArguments allows argument lists which are longer than the maximum arity of an invoke call. For more details, see the API documentation for the java.lang.invoke package.

(Paragraph jvms-6.5.invokedynamic.desc-200 is deleted.) The symbolic reference R describes a method which is signature polymorphic (§2.9). Due to the operation of invokevirtual on a signature polymorphic method called invoke,

(Paragraph jvms-6.5.invokedynamic.desc-210 is deleted.) If the bootstrap method is a variable arity method, then some or all of the arguments on the operand stack specified above may be collected into a trailing array parameter.

The invocation of a bootstrap method occurs within a thread that is attempting resolution of the symbolic reference to the call site specifier of this dynamic call site. If there are several such threads, the bootstrap method may be invoked in several threads concurrently. Therefore, bootstrap methods which access global application data must take the usual precautions against race conditions.

The result returned by the bootstrap method must be a reference to an object whose class is java.lang.invoke.CallSite or a subclass of java.lang.invoke.CallSite. This object is known as the call site object. The reference is popped from the operand stack used as if in the execution of an invokevirtual instruction.

(Note: When a bootstrap method is used to resolve a dynamic call site, it must return a java.lang.invoke.CallSite object to complete the linkage of the call site. When a bootstrap method is used to resolve a dynamic constant, it is required to return a reference to an object which can be converted, via casting, unboxing, and/or widening, to the required field type of the constant.)

If several threads simultaneously execute the bootstrap method for the same dynamic call site, the Java Virtual Machine must choose one returned call site object and install it visibly to all threads. Any other bootstrap methods executing for the dynamic call site are allowed to complete, but their results are ignored, and the threads’ execution of the dynamic call site proceeds with the chosen call site object.

@@ -20239,27 +20298,69 @@

value, is pushed onto the operand stack.

Otherwise, if the run-time constant pool entry is a symbolic reference to a class (§5.1), then the named class is resolved ([§5.4.3.1]) and a reference to the Class object representing that class, value, is pushed onto the operand stack.

Otherwise, if the run-time constant pool entry must be is a symbolic reference to a method type or a method handle (§5.1). The (§5.1), then the method type or method handle is resolved ([§5.4.3.5]) and a reference to the resulting instance of java.lang.invoke.MethodType or java.lang.invoke.MethodHandle, value, is pushed onto the operand stack.

Otherwise, the run-time constant pool entry must be a symbolic reference to a dynamic constant specifier. This specifier is resolved ([§5.4.3.6]) to obtain a reference to a java.lang.invoke.MethodHandle instance that will serve as the bootstrap method, a reference to a java.lang.Class instance for the constant’s field type, and references to static arguments. The bootstrap method is invoked using the same rules for resolving a dynamic call site of an invokedynamic instruction, although with four differences:
  • The resolution is performed once per distinct constant pool entry, not once per distinct invokedynamic instruction,
  • instead of resolving a java.lang.invoke.MethodType object for the type argument of the bootstrap method, a java.lang.invoke.Class object is resolved to reify the field type descriptor of the constant, and
  • likewise, when passing a java.lang.String object for the name argument of the bootstrap method, a field name is passed to reify the name of the constant,
  • instead of requiring a java.lang.invoke.CallSite result, the result of the bootstrap method is converted to the required field type of the constant, as if by casting, unboxing, and/or widening.
All other aspects are the same, including support for large numbers of static arguments (via invokeWithArguments), support for a two-argument bootstrap method taking a java.lang.invoke.BootstrapCallInfo object, the rules for converting exceptions into errors, and the resolution of races when multiple threads concurrently perform linkage. Editor Note: The common logic for applying bootstrap methods should be moved out of the invokedynamic instruction specification and placed somewhere it can be shared in common by the various use cases for bootstrap methods. There may even be more use cases in the future.