Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces (original) (raw)

David Holmes david.holmes at oracle.com
Tue Nov 20 06:31:42 UTC 2012

Hi Mike,

Minor typos and inconsistencies:

DoubleBinaryOperator.java

28 * Combines two {@code double} operands producing an {@code double} result.

an -> a

51 * @param rightvalue used as the right operand

Need space after right

52 * @return result value of the operation

"result value" doesn't read right - just "@return the result of ..." - as for BinaryOperator.operate

General consistency: all like methods in a family of interfaces should use the same wording. Eg BinaryOperator.operate says "upon the provided operands" whereas DoubleBinaryOperator.* says "upon the operands". Ditto across families ie UnaryOperator and BinaryOperator should use consistent terminology for operands and results.

DoubleBlock.java:

31 * @param The type of input objects to {@code accept}.

DoubleBlock is not a generic type. (Surely this should be generating a javadoc warning?)

DoubleFunction.java

32 * @param the type of input objects to the {@code apply} operation.

You now potentially have multiple operation methods, and T refers to the input of all of them.

General consistency comments across everything:

Function.java

33 * @param the type of output objects from {@code apply} operation.

from -> from the

43 * @param t the input object to be to which the function will be applied.

delete "to be" ? Or else re-word.

UnaryOperator.java

28 * Operator on a single operand.

Operator -> operate ?

30 * @param the type of input objects to {@code operate} and of the result.

objects -> object

Cheers, David

On 20/11/2012 2:55 PM, Mike Duigou wrote:

I have posted another revision at

http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/ This version contains some method remaining in the {I|L|D}UnaryOperation and {I|L|D}BinaryOperator and a few Javadoc fixes. The package javadoc ie. package-info.java, is known to be a weak point right now. We're still debating what must be said here and what would be better said attached to the APIs which consume these functional interfaces. We don't anticipate many (any?) further changes to the naming before commit at this point. Mike On Nov 13 2012, at 17: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

More information about the core-libs-dev mailing list