Primitive streams and optional (original) (raw)

Doug Lea dl at cs.oswego.edu
Sat Nov 24 14:14:47 PST 2012

On 11/24/12 16:41, Brian Goetz wrote:

Note the somewhat subtle consequences of this last sentence, which is the really painful one for me (I'm not as attached to Optional): it means that you cannot count on any stream pipeline being size-preserving or index-preserving, because nulls inputs (or intermediate values) will be silently compressed out, breaking the correspondence between input and output indexes even for size-preserving ops. (I would prefer that nulls simply not have been allowed in collections, but that ship sailed already.) For example:

T[] mapped = Arrays.stream(input).map(mapper).toArray();

I'm not bothered. The implementation can assume size-preservingness and fall back to slow secondary copy etc if it is wrong after final check of how many elements it saw. toArray already does this (in the case of unexpected growth). People may then learn that things are slower if they put nulls in the their collections.

(Aside: plain arrays (vs ArrayLists) have always been marginal candidates for stream-style processing. There's still reason to reinvent ParallelArray someday...)

Also, what's the corresponding proposal for primitive streams? I would hate to force boxing onto users of: Integer x = intStream.filter(...).findFirst(); just because we don't have an int sentinal we can use.

Why so hateful? It's the Java Way :-)

-Doug

More information about the lambda-libs-spec-observers mailing list