Inconsistency in Java 8 method signatures

Question

Java 8 has given us new methods with really long signatures like this:

static <T,K,U,M extends Map<K,U>> Collector<T,?,M> toMap(
    Function<? super T,? extends K> keyMapper, 
    Function<? super T,? extends U> valueMapper, 
    BinaryOperator<U> mergeFunction, Supplier<M> mapSupplier)

What I find odd about this is that wildcards have been used to ensure that the first two parameters are as general as possible, yet the third parameter is just a BinaryOperator<U>. If they'd been consistent, surely it would be a BiFunction<? super U,? super U,? extends U>?. Am I missing something? Is there a good reason for this, or did they just want to avoid making an already horrendous signature even worse?

Edit

I understand PECS, and I understand the principle that mergeFunction should be thought of as a way of taking two Us and getting back a U. However it would be useful to be able to have an object that could be reused in many different ways. For example:

static final BiFunction<Number, Number, Double> 
        MULTIPLY_DOUBLES = (a, b) -> a.doubleValue() * b.doubleValue();

Obviously this is not a BinaryOperator<Double>, but it could be treated as one. It would be great if you could use MULTIPLY_DOUBLES as both a BiFunction<Number, Number, Double> and a BinaryOperator<Double>, depending on the context. In particular, you could simply pass MULTIPLY_DOUBLES to indicate that you want a load of doubles to be reduced using multiplication. However the signature for toMap (and other new methods in Java 8) does not allow for this kind of flexibility.

@GriffeyDog I know that. I think what I've written would be a more general signature, not an equivalent one. — Paul Boddington, Mar 24 '15 at 20:34
@pbabcdefp the _principle_ of an `*Operator` is to operate on the same input and output arguments; as such `super`ing arguments and `extends`ing return values would make no sense. — fge, Mar 24 '15 at 20:36
And suddenly Java closures just got a lot less appealing to me. — robbmj, Mar 24 '15 at 20:39
@robbmj with type inference and IDEs you don't notice. It's not too bad — dkatzel, Mar 24 '15 at 20:39
@dkatzel If I were to write a library that accepts closures, would this signature be typical? — robbmj, Mar 24 '15 at 20:42
"to avoid making an already horrendous signature even worse" seems like a good guess. Sure, some flexibility was sacrificed, but (relative) simplicity of the API may have been deemed more valuable. — VGR, Mar 24 '15 at 20:49
No, you've got the explanation right. This would work if it was the broader `BiFunction`, but they did want to minimize the signature complexity -- and more importantly, a narrower signature makes it easier for type inference to work, so you can just pass in an untyped lambda and have it inferred correctly. — Louis Wasserman, Mar 24 '15 at 20:49
@fge I've edited the question to show the kind of thing I'd like to be able to do. I get your point, but I think it makes the API less flexible. — Paul Boddington, Mar 24 '15 at 21:16
Ironically, [`Map.merge`](http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#merge-K-V-java.util.function.BiFunction-) where `mergeFunction` will end up *does* accept a `BiFunction super V,? super V,? extends V>`. — Holger, Mar 25 '15 at 11:32
@Holger thanks for that. Interesting. That shows it wasn't a stupid question! — Paul Boddington, Mar 25 '15 at 11:36

score 3 · Answer 1 · edited Jun 20 '20 at 09:12

the BinaryOperator<U> mergeFunction needs to take Us from an input source and put them into another consumer.

Due to the Get and Put Principle, the type has to be exactly the same. No wild cards.

The get-put principle, as stated in Naftalin and Wadler's fine book on generics, Java Generics and Collections says:

Use an extends wildcard when you only get values out of a structure, use a super wildcard when you only put values into a structure, and don't use a wildcard when you do both.

Therefore it can't beBiFunction<? super U,? super U,? extends U> mergefunction because we are doing get and put operations. Therefore the input and result type must be identical.

see these other links for more about Get and Put:

Explanation of the get-put principle (SO question)

http://www.ibm.com/developerworks/library/j-jtp07018/

EDIT

As Gab points out, the Get and Put principle is also known by the Acronym PECS for "Producer Extends Consumer Super"

What is PECS (Producer Extends Consumer Super)?

@Gab Thanks! Forgot about that acronym. Updated answer – dkatzel Mar 24 '15 at 21:02 — dkatzel, Mar 24 '15 at 21:02

score 3 · Accepted Answer · answered Mar 25 '15 at 12:18

You are right in that the functional signature of the merge operation (the same applies to reduce) does not require an interface like BinaryOperator.

This can not only be illustrated by the fact that the mergeFunction of the toMap collector will end up at Map.merge which accepts a BiFunction<? super V,? super V,? extends V>; you can also convert such a BiFunction to the required BinaryOperator:

BiFunction<Number, Number, Double> 
    MULTIPLY_DOUBLES = (a, b) -> a.doubleValue() * b.doubleValue();
Stream<Double> s = Stream.of(42.0, 0.815);
Optional<Double> n=s.reduce(MULTIPLY_DOUBLES::apply);

or full generic:

public static <T> Optional<T> reduce(
    Stream<T> s, BiFunction<? super T, ? super T, ? extends T> f) {
    return s.reduce(f::apply);
}

The most likely reason for creating BinaryOperator and UnaryOperator is to have symmetry with the primitive type versions of these functions which don’t have such a super interface.

In this regard, the methods are consistent

Stream.reduce(BinaryOperator<T>)
IntStream.reduce(IntBinaryOperator)
DoubleStream.reduce(DoubleBinaryOperator)
LongStream.reduce(LongBinaryOperator)

or

Arrays.parallelPrefix(T[] array, BinaryOperator<T> op)
Arrays.parallelPrefix(int[] array, IntBinaryOperator op)
Arrays.parallelPrefix(double[] array, DoubleBinaryOperator op)
Arrays.parallelPrefix(long[] array, LongBinaryOperator op)

score 2 · Answer 3 · answered Mar 24 '15 at 22:10

2

Looking at the implementation of the Collectors#toMap in question, one can see that the operator is passed through to some other methods, but eventually only arrives as the remappingFunction in various forms of Map#merge(K key, V value, BiFunction<? super V,? super V,? extends V> remappingFunction).

So using BiFunction<? super V, ? super V, ? extends V> instead of BinaryOperator<V> would indeed work here, without causing any problem. But not only here: The BinaryOperator is only a specialization of BiFunction for the case that the operands and the result are all of the same type. So there are many places where one could allow passing in a BiFunction<? super V, ? super V, ? extends V> instead of a BinaryOperator<V> (or, more obviously: One could always use a BiFunction<V, V, V> instead...)

So up to this point, there seems to be no technical reason why they chose to only support a BinaryOperator<U>.

There was already speculation about possible non-technical reasons. For example, limiting the complexity of the method signature. I'm not sure whether this applies here, but it could, indeed, be a trade-off between the complexity of the method and the intended application cases: The concept of a "binary operator" is easily comprehensible, for example, by drawing analogies to a simple addition or the union of two sets - or maps, in this case.

A possible not-so-obvious technical reason could be that there should be the possibility to provide implementations of this method that internally would not be able to cope with the BiFunction. But considering that the BinaryOperator is only a specialization, it's hard to imagine what such an implementation should look like.

answered Mar 24 '15 at 22:10

Marco13

53,703
9
80
159

@Holger what obsolete additional interface are you referring to? `BinaryOperator`? – Paul Boddington Mar 25 '15 at 11:54
@pbabcdefp: Yes, if every use of a `BinaryOperator` was instead using `BiFunction` or `BiFunction super X,? super X,? extends X>`, there was no need for that `interface`. – Holger Mar 25 '15 at 12:00
@Holger Same with `UnaryOperator`. Those 2 additional interfaces actually reduce flexibility – Paul Boddington Mar 25 '15 at 12:01
@Holger. Symmetry with primitive versions is the most convincing explanation I've seen for this. If you make it an answer I'll accept it. – Paul Boddington Mar 25 '15 at 12:02
@pbabcdefp I also considered something like the "symmetry", but mainly referring to other operations that might build upon (or be simplified versions of) the `toMap` function. But interestingly, the symmetry argument does *not* hold for the particular `toMap` method... – Marco13 Mar 25 '15 at 13:40
@Marco13 You're right there isn't a primitive version of `toMap`. But the "symmetry" argument (I agree it's not the right word) is a plausible explanation of why they decided in general to use `UnaryOperator` and `BinaryOperator` rather than `Function super U,? extends U>` and `BiFunction super U,? super U,? extends U>`. I upvoted your answer and accepted Holger's, but it was pretty arbitrary. – Paul Boddington Mar 25 '15 at 13:53
1

@pbabcdefp I did not want to argue or bargain here ;-) Strictly speaking, **ALL** functional interfaces could have been offered as a single interface: `Function`. That's it (with `A` being something like a `Tuple`, for `Bi`- and higher arity functions). But the designers made some reasonable decisions about which functions should be offered in a "fixed" form (like `BinaryOperator`), and for which functions a dedicated, primitive version should exist. It probably was not easy, and some people might complain e.g. about missing `Float`-primitive versions etc., but that's a different story... – Marco13 Mar 25 '15 at 14:38
@Marco13 That's true, although personally I'm glad Java doesn't have `Pair` or `Tuple`. I think it's fair to say that if there was `IntUnaryOperator` but not `UnaryOperator` there would be people on here asking why that is (probably me!). – Paul Boddington Mar 25 '15 at 14:42

Inconsistency in Java 8 method signatures

3 Answers3

Linked