Mike,
Some small comments.
1) IntUnaryOperator.java
Typo in:
+ 30 * <p>This is the primitive type specialization of {@link
IntUnaryOperator} for
+ 31 * {@code int} and also may be used as a {@code
IntUnaryOperator<Integer>}. When
+ 32 * used as a {@code IntUnaryOperator} the default {@code
operate} implementation
+ 33 * provided by this interface neither accepts null parameters
nor does it return
+ 34 * null results.
IntUnaryOperator -> UnaryOperator
2) Double/Int/Long Function
"When used as a Function the default apply implementation provided
by this interface neither accepts null parameters nor does it
return null results."
"When used as a Function", is this really necessary, or should the
behavior of the default apply method just be described?
Why the restriction on null parameters, it seems overly restrictive
since applyAsXXXX accepts nulls, right?
3) package description
"null values are accepted and returned by these functional
interfaces according to the constraints of the specification in
which the functional interfaces are used. The functional interfaces
themselves do not constrain or mandate use of null values. Most
usages of the functional interfaces will define the role, if any,
of null for that context."
Given these changes, doesn't this need to be reworked ( to indicate
that some methods specify null value behavior)?
4) Trivially, IntSupplier is missing a '<p>', before "This is the
primitive type..."
5) I agree with David, NPE should be defined where applicable.
-Chris.
On 12/06/2012 06:06 AM, David Holmes wrote:
On 6/12/2012 4:20 AM, Mike Duigou wrote:
I have updated webrev again to fix some reported javadoc technical
issues and added null handling specification to the
{Int|Double|Long}Supplier.
http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/
http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html
I believe that this iteration is complete (or very nearly so).
Sorry to be a pain but this:
left - the left operand, must be non-null
doesn't tell you what happens if it is null. Is it not better to simply
have:
@param left the left operand
@param right the right operand
@throws NullPointerException if either left or right are null
?
David
-----
Mike
On Dec 4 2012, at 21:47 , Mike Duigou wrote:
Hello all;
I have updated the proposed patch. The changes primarily add class
and method documentation regarding handling of null for the primitive
specializations.
http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/
http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html
I've also reformatted the source for the default methods.
Mike
On Nov 26 2012, at 18:12 , Mike Duigou wrote:
Hello all;
In the original patch which added the basic lambda functional
interfaces, CR#8001634 [1], none of the interfaces extended other
interfaces. The reason was primarily that the javac compiler did
not, at the time that 8001634 was proposed, support extension
methods. The compiler now supports adding of method defaults so this
patch improves the functional interfaces by filing in the
inheritance hierarchy.
Adding the parent interfaces and default methods allows each
functional interface to be used in more places. It is especially
important for the functional interfaces which support primitive
types, IntSupplier, IntFunction, IntUnaryOperator,
IntBinaryOperator, etc. We expect that eventually standard
implementations of these interfaces will be provided for functions
like max, min, sum, etc. By extending the reference oriented
functional interfaces such as Function, the primitive
implementations can be used with the boxed primitive types along
with the primitive types for which they are defined.
The patch to add parent interfaces and default methods can be found
here:
http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
Mike
[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697
