JDK-8028690 : Lambda Spec: Clarify how parameter/return types are derived for MethodHandle::invoke
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-11-20
  • Updated: 2014-02-26
  • Resolved: 2013-12-17
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 8
8Fixed
Related Reports
Relates :  
JDK-8028739 - javac generates incorrect descriptor for MethodHandle::invoke
Relates :  
JDK-8028129 - Type checking: signature polymorphic MethodHandle.invoke(Object[])
Description
A method reference with a compile-time declaration that is signature-polymorphic (MethodHandle.invoke or MethodHandle.invokeExact) gets special treatment in 15.12.3 when determining the parameter/return types of the invocation.  The mapping from a method reference expression to a method invocation expression, for the purpose of deriving these types, is not spelled out.

Expected behavior:
- The types of the parameters are derived from the targeted function type's parameter types.
- The return type is 'void' if the targeted function type has a 'void' return, and Object otherwise.
Comments
Updated spec text for 15.28.3: If the method reference has the form ExpressionName ... If the method reference has the form super ... If the method reference has the form ReferenceType ... If the method reference has the form ClassType ... If the method reference has the form, for some k ��� 1, Type [] ... ***In any case, if the compile-time declaration of the method reference is signature polymorphic (15.12.3), then:*** - ***The types of the parameters for the invocation are the types of the corresponding arguments.*** - ***The result type is void if the invocation method's return type is void, and Object otherwise.*** To evaluate the method reference, the following steps are taken: ...
17-12-2013
I think the proper treatment of the return type is that it should be either Object or void. Signature polymorphic methods only derive special return types from a target type when they appear in a casting context. The invocation corresponding to a method reference does not appear in a casting context.
17-12-2013
Thanks for spotting that, John. I've reported a separate bug for javac, JDK-8028739.
20-11-2013
Update of test case from JDK-8028129 to validate expected exception, and then elicit a new (unexpected) exception from the current implementation.
20-11-2013
The return type should be exactly the targeted function type's return type, which may be (the non-type) void, a subtype of Object, or a primitive type. And similarly with the arguments. There should be no special treatment for the nominally declared native method signature (Object���)Object. The recorded call descriptor should be ([Ljava/lang/Object;)Ljava/lang/Object; if and only if the targeted function type is (after erasure) exactly (Object[])Object. But, it may be simpler to disallow mh::invoke, on the grounds that MethodHandle.invoke appears to be infinitely overloaded. If there are multiple candidate targeted function types, the method reference mh::invoke should happily match to any or all of them.
20-11-2013