Bug ID: JDK-8199051 5.4.3.6: Require first parameter type of a condy bootstrap to be Lookup

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11
11Fixed

CONSTANT_Dynamic resolution occurs by invoking a bootstrap method via 'invokeWithArguments', passing an array of arguments. The first three arguments are invocation metadata���a Lookup, a name, and a Class. If the arguments can't be cast to the bootstrap method's input types, the invocation fails.

To facilitate more flexible bootstrap method calling conventions in the future, we'd like to require that the first parameter has type MethodHandles.Lookup. If a bootstrap does not conform, an error will occur, with the possibility of using a different calling convention in the future.

This change rejects bootstraps like the following, which can currently be invoked without error:
static Foo bootstrap(Object lookup, String name, Class<?> type)
static Foo bootstrap(Object... args)

For compatibility, no change is proposed to the resolution behavior for invokedynamic bootstraps.

The mention of a Class object is redundant in: "..., then it must be the case that the first parameter type of the `java.lang.invoke.MethodType` of the `java.lang.invoke.MethodHandle` is a `Class` representing the class `java.lang.invoke.MethodHandles$Lookup`." It is sufficient to say: "..., then let D be the type descriptor of the bootstrap method handle. (That is, D is a reference to an instance of java.lang.invoke.MethodType.) The first parameter type indicated by D must be `java.lang.invoke.MethodHandles$Lookup`, or else resolution fails ..." In addition, the note about a dynamically-computed call site generates more heat than light. It's not clear if "other compatible type" is in reference to Object being a superclass of MethodHandles.Lookup, or in reference to the type of an actual argument to the BMH.

01-05-2018

Proposed changes to 5.4.3.6 (using current 11 draft spec as a baseline): 1. _R_ gives a symbolic reference to a bootstrap method handle. The bootstrap method handle is resolved ([5.4.3.5]) to obtain a `reference` to an instance of `java.lang.invoke.MethodHandle`. Any exception that can be thrown as a result of failure of resolution of a symbolic reference to a method handle can be thrown in this step. **If _R_ is a symbolic reference to a dynamically-computed constant, then it must be the case that the first parameter type of the `java.lang.invoke.MethodType` of the `java.lang.invoke.MethodHandle` is a `Class` representing the class `java.lang.invoke.MethodHandles$Lookup`. If not, resolution fails with a `BootstrapMethodError`.** > **In contrast, for historical reasons, a dynamically-computed call site may be resolved using a bootstrap method handle whose first parameter type is `Object` or some other compatible type, as determined by the `invokeWithArguments` invocation described below.**

05-03-2018

Relates :	JDK-8177279 - JEP 309: Dynamic Class-File Constants
Relates :	JDK-8199875 - Require first parameter type of a condy bootstrap to be Lookup