Primitive streams and optional

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