RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries

David Holmes david.holmes at oracle.com
Tue Feb 19 05:29:19 UTC 2013

Hi Mike,

In BinaryOperator.java this sentence doesn't read correctly:

+ * An operation upon two operands yielding a result. This is a 
specialization of
+ * {@code BiFunction} for the operands and the result are all being of 
the same
+ * type.


{@code BiFunction} for the case where the operands and the result are 
all of the same type.

{@code BiFunction} where the operands and the result are all of the same 


DoubleUnaryOperator.java - this changed wording seems more awkward than 
the original:

-     * Returns the {@code double} result of the operation upon the
+     * Returns a {@code double} value result of the operation upon the
       * {@code double} operand.



+ * @param <R> the type of result of the {@code apply} operation.

Either "the type of the result of the ...", or "the type of result from 
the ..."


General comment regarding specializations of Function. If we have 
Function<T, R> where R is the result type, then in the specializations 
which specialize the input type (T) then we should use R for the 
remaining type variable eg IntFunction<R> rather than IntFunction<T>


In LongFunction:

+     * @param l the input value

why use l as the parameter name? I presume for "long" but why? I thought 
the "i" parameter in IntFunction was so named for "input". I would much 
rather see a common parameter naming scheme being used (i, t, val, arg - 
any of these).



This sentence doesn't read right:

+ * result are of the same type. This is a specialization of {@code 
Function} for
+ * the operand and the result of the same type.


"This is a specialization of {@code Function} for the case where the 
operand and result are of the same type."



I've flagged this elsewhere but you may not have seen it:

+ *     Predicate<String>

If we use < then we should also use >.



+ * is the two-arity specialization of {@link Consummer}

typo: Consummer

+ * @param <R> the type of output objects from {@code apply} operation.

from -> from the


The *BiXXX types are not consistently documented. For example:

BiFunction has:

+ * @param <T> the type of input objects provided to the {@code apply} 
+ * @param <U> the type of input objects provided to the {@code apply} 

while BiPredicate has:

+ * @param <T> the type of the first argument to {@code test}.
+ * @param <U> the type of the second argument to {@code test}.

I prefer the BiPredicate form.



+ * Determines if the {@code long} input value matches some criteria. 
This is the
+ * {@code double}-consuming primitive type specialization of {@link 

The first "long" should be "double".



+ * Apply a function to the input argument,

argument -> arguments


Aside: it would be much easier to maintain consistent style if we used a 
"template" to define the main outline of each family of interfaces and 
generated the specializations from that (similar to how we generate the 
various bytebuffer classes).


On 16/02/2013 6:13 AM, Mike Duigou wrote:
> Hello All;
> This patch introduces a number of new functional interfaces for use by the lambda libraries. Also included are some name changes following JSR-225 EG review. The new interfaces are:
> BiConsumer
> BiFunction
> BiPredicate
> BooleanSupplier
> DoublePredicate
> IntPredicate
> LongPredicate
> ObjDoubleConsumer
> ObjIntConsumer
> ObjLongConsumer
> ToDoubleBiFunction
> ToDoubleFunction
> ToIntBiFunction
> ToIntFunction
> ToLongBiFunction
> ToLongFunction
> Renames:
> Block -> Consumer
> BiBlock -> BiConsumer
> IntBlock -> IntConsumer
> DoubleBlock -> LongConsumer
> LongBlock -> LongConsumer
> UnaryOperator.operate -> UnaryOperator.apply
> LongUnaryOperator.operateAsLong -> LongUnaryOperator.applyAsLong
> DoubleUnaryOperator.operateAsDouble -> DoubleUnaryOperator.applyAsDouble
> IntUnaryOperator.operateAsInt -> IntUnaryOperator.applyAsInt
> LongBinaryOperator.operateAsLong -> LongBinaryOperator.applyAsLong
> DoubleBinaryOperator.operateAsDouble -> DoubleBinaryOperator.applyAsDouble
> IntBinaryOperator.operateAsInt -> IntBinaryOperator.applyAsInt
> All of the changes outside the java.util.function package are made to accommodate these renamings.
> The webrev is located at:
> http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/webrev/
> and specdiff for the java.util.function package is at:
> http://cr.openjdk.java.net/~mduigou/JDK-8004561/1/specdiff/
> Thanks!
> Mike

More information about the core-libs-dev mailing list