JDK-8151179 : address issues raised by JCK team on JEP 274 API
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-03-03
  • Updated: 2017-10-11
  • Resolved: 2016-09-28
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 9
9 b139Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8150729 :  
JDK-8150964 :  
JDK-8151026 :  
JDK-8151736 :  
JDK-8151738 :  
JDK-8151894 :  
JDK-8151903 :  
JDK-8152008 :  
JDK-8152020 :  
JDK-8152559 :  
JDK-8152570 :  
JDK-8152584 :  
JDK-8156065 :  
JDK-8156868 :  
JDK-8158110 :  
JDK-8159469 :  
JDK-8161069 :  
JDK-8161070 :  
JDK-8161127 :  
Description
This is the umbrella issue for all commentary on JEP 274 API documentation made by the JCK team.
Comments
Under this umbrella issue, there is a collection of subtasks concerned with documentation issues raised by [~asolodkaya]. Some of them, in particular JDK-8151736, get longer and longer, and the documentation gets ever more complicated. What this results in is not good API. It is completely overloaded with detailed discussions of the intricate relations between the parameter handles passed to the convenience wrappers abstracting from the generic loop combinator, MHs.loop(), also called the Mother Of All Loops (MOAL). At the root of this lies the expectation that all the parameter type list and omitted-handle inference goodness that the MOAL does should be available to the convenience wrappers as well. The problem is due to the fact that the convenience wrappers do their own fair share of MH combination, introducing new dependencies. Ultimately, the API documentation for the wrappers ends up documenting their implementation in great detail (by way of meticulously describing the effects of the MOAL's inference logic on the wrappers), leading to convenience (!) wrappers that are very inconveniently (!) documented. We should take a step back here. Work will proceed as follows: 1. Allow inference to the full degree only for the MOAL (leave it as it is). 2. Expect all arguments to be fully expressed for the convenience wrappers (no null inference, only very limited parameter type inference), and use strong language ("must") in the API docs to make this clear. Disallowing null inference is in line with what, e.g., MHs.guardWithTest() supports.
17-06-2016

Tested JDK: JDK 9 120 compact1 JCK: 9 b36 Testsuite: JCK-runtime-9 OS: Ubuntu.Linux.14.04 RULE "api/java_lang/invoke/MethodHandles/DoWhileLoop/index_DoWhileLoopTests" TestCase [implementationEqualsLimitWithVoidInit] Exceptions are different: null and java.lang.IllegalArgumentException: parameter type cannot be void RULE "api/java_lang/invoke/MethodHandles/WhileLoop/index_WhileLoopTests" TestCase [implementationEqualsIncrementWithVoidInit] Exceptions are different: null and java.lang.IllegalArgumentException: parameter type cannot be void RULE "api/java_lang/invoke/MethodHandles/WhileLoop/index_WhileLoopTests" TestCase [implementationEqualsIncrementWithNullPred] Exception messages are different Expected equal to : "no predicate found: [null, null]", was given: "parameter type cannot be void" RULE "api/java_lang/invoke/MethodHandles/WhileLoop/index_WhileLoopTests" TestCase [implementationEqualsIncrementWithNullBody] Exceptions are different: null and java.lang.IllegalArgumentException: parameter type cannot be void
31-05-2016