Why is `Stream.collect` type-safe and `Stream.toArray(IntFunction)` is not?

Question

Consider the following code fragment

String strings[] = {"test"};
final List<String> collect = java.util.Arrays.stream(strings).collect(java.util.stream.Collectors.toList());
final Double[] array = java.util.Arrays.stream(strings).toArray(Double[]::new);

Why can Java guarantee the correct type in the collect-case (changing the generic type of collect to e.g. Double leads to a compile time error), but not in the array case (compiles fine, despite apply(int) of Double[]::new gives a Double[], not an Object[], but throws ArrayStoreException if used incorrectly as above)?

What would be the best way to generate a compile time error in case I change the type of the stream without changing the given IntFunction in the toArray call?

score 12 · Accepted Answer · edited Jan 23 '19 at 03:40

12

The signature of the method Stream::toArray looks as follows. Please note that the type parameters T and A are completely unrelated.

public interface Stream<T> {
    <A> A[] toArray(IntFunction<A[]> generator);
}

In the source of ReferencePipeline.java, you can find the following comment:

Since A has no relation to U (not possible to declare that A is an upper bound of U) there will be no static type checking. Therefore use a raw type and assume A == U rather than propagating the separation of A and U throughout the code-base. The runtime type of U is never checked for equality with the component type of the runtime type of A[]. Runtime checking will be performed when an element is stored in A[], thus if A is not a super type of U an ArrayStoreException will be thrown.

edited Jan 23 '19 at 03:40

Naman

27,789
26
218
353

answered May 21 '14 at 17:51

nosid

48,932
13
112
139

Is this one of the cases where `A super T` would help? If so, then it is quite interesting that they haven't fixed it for this as it seems like a "must" to me if it's in such an API. – skiwi May 21 '14 at 17:57
Well, I am looking for the reason that they are completely unrelated, as you pointed out. Putting an `` would seem easy enough. Thus I would expect some problem entailed in the implementations of the Stream interface or something like that. – muued May 21 '14 at 18:17
9

@muued Please note that `` is *syntactically* not possible in type declarations. You can only have `? super T` as a type, but you can not capture the `?`. This is as opposed to `X extends T` that can capture `? extends T`. It was omitted from Java at the time generics were created because it was deemed *not useful enough*. – skiwi May 21 '14 at 19:08
@skiwi ah, that perfectly explains it, thanks. So the missing super you mentioned and the fact, that one cannot distinguish methods by generic types preventing them from adding a `T[] toArray(IntFunction generator);` leads to the misery we have now – muued May 21 '14 at 19:59
2

@skiwi The problem is not unique to the streams API. [`Collection.toArray(T[])`](https://docs.oracle.com/javase/7/docs/api/java/util/Collection.html#toArray(T[])) is an equally valid use case, so if that wasn't compelling enough to support `super`, no reason why this would be. – shmosel Aug 23 '16 at 19:53

Why is `Stream.collect` type-safe and `Stream.toArray(IntFunction)` is not?

1 Answers1