Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces

[Alan Bateman]

On 14/11/2012 01:19, Mike Duigou wrote:
> Hello all;
>
> I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again:
>
> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/
>
> Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-)
>
> This update includes:
>
> - Block.apply renamed to Block.accept
> - {Int|Long|Double}Block specializations added.
> - Commented out "extends Combiner<T,T,T>" in BinaryOperator was removed for now since Combiner is out of scope for this review.
> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going.
> - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation.
> - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation.
>
> Mike
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html
>
Just a few incy wincy comments on the latest webrev:

- Don't forget functions->function in make/java/java/Makefile.

- The @return in Predicate - it might read a bit better if there were a 
comma before "otherwise".

- In the package description it reads "All functional interface 
implementations are expected to" but this doesn't flow well into the 
bullet point. It may be better to re-word this sentence to something 
like "Implementators of functional interfaces should keep in mind:".

-Alan.