RFR(L): 8139885: implement JEP 274: enhanced method handles

Michael Haupt michael.haupt at oracle.com
Thu Nov 19 21:16:50 UTC 2015


Hi John, Paul,

thanks for your reviews - they have helped me polish the code and documentation some more and add some more tests. The result is at http://cr.openjdk.java.net/~mhaupt/8139885/webrev.02

I noticed both of you emphasised how the Streams API helps the implementation - I second that. Streams "made my day" there. :-)

I'm replying below to those of your remarks I didn't address in the new webrev.

> Am 19.11.2015 um 05:25 schrieb John Rose <john.r.rose at oracle.com>:
> My usual practice, though, is to move argument checking and error reporting code out of line, away from the main logic.  I think this is good style, and it gives the JIT a little bit (a very little bit) of help.

In the most generic loop combinator, the tests are somewhat dispersed over the implementation because they depend on results that are not readily available at the beginning of the method's execution. I haven't put them all in one test method because I prefer early failure with clear messages over possibly hard to interpret failure due to inconsistencies in mid-run.

> One wishful item:  It would be nice if the javadoc examples could be integrated into JavaDocExamplesTest.java.  I see that is messy since we are now using TestNG instead of JUnit.  The point of JavaDocExamplesTest was to make it easy to "sync" the javadoc with the examples, by having one place to copy-and-paste the javadoc.

I've filed this RFE for that: https://bugs.openjdk.java.net/browse/JDK-8143343

> Am 19.11.2015 um 11:45 schrieb Paul Sandoz <paul.sandoz at oracle.com>:
> I have a mild preference to maintain the 80 char limit for JavaDoc, to me it’s easier to read. For code i don’t mind a 100 or more limit.

The formatting in the files I've touched is inconsistent; I'll stick with the 120 character limit for both code and Javadoc.

> 3458      * The loop handle's result type is the same as the sole loop variable's, i.e., the result type of {@code init}.
> 
> s/variable’s/variable ?

No; the genitive is intentional (result type = loop variable type, rather than result type = loop variable).

> I guess in the future there may be ample opporunity to specialize the generic “loop” mechanism with LambdaForms?

Yep: https://bugs.openjdk.java.net/browse/JDK-8143211

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment




More information about the core-libs-dev mailing list