-
Bug
-
Resolution: Fixed
-
P3
-
None
-
b108
-
Not verified
These two excerpts from the documentation of MethodHandles.tryFinally() contradict each other:
"The pseudocode for the resulting adapter looks as follows. In the code, {@code V} represents the result type of the {@code try/finally} construct; {@code A}/{@code a}, the types and values of arguments to the resulting handle consumed by the cleanup; and {@code B}/{@code b}, those of arguments to the resulting handle discarded by the cleanup."
"The {@code target} and {@code cleanup} handles' return types must be the same. Their parameter type lists also must be the same, but the {@code cleanup} handle must accept one or two more leading parameters"
Also, several handle combinators' documentation should be extended with this hint:
+ * <p>
+ * Note: The resulting adapter is never a {@linkplain MethodHandle#asVarargsCollector
+ * variable-arity method handle}, even if the original target method handle was.
This applies to MH.bindTo(), MHs.insertArguments(), MHs.filterArguments(), MHs.filterReturnValue(), and any other combinator which (usually) leaves a trailing argument list invariant, and therefore may surprise users when it produces a non-varargs output from a varargs input.
"The pseudocode for the resulting adapter looks as follows. In the code, {@code V} represents the result type of the {@code try/finally} construct; {@code A}/{@code a}, the types and values of arguments to the resulting handle consumed by the cleanup; and {@code B}/{@code b}, those of arguments to the resulting handle discarded by the cleanup."
"The {@code target} and {@code cleanup} handles' return types must be the same. Their parameter type lists also must be the same, but the {@code cleanup} handle must accept one or two more leading parameters"
Also, several handle combinators' documentation should be extended with this hint:
+ * <p>
+ * Note: The resulting adapter is never a {@linkplain MethodHandle#asVarargsCollector
+ * variable-arity method handle}, even if the original target method handle was.
This applies to MH.bindTo(), MHs.insertArguments(), MHs.filterArguments(), MHs.filterReturnValue(), and any other combinator which (usually) leaves a trailing argument list invariant, and therefore may surprise users when it produces a non-varargs output from a varargs input.
- relates to
-
JDK-8130227 JEP 274: Enhanced Method Handles
-
- Closed
-