Additional method on Stream

Kasper Nielsen kasperni at
Tue Apr 28 08:22:45 UTC 2015

On Tue, Apr 28, 2015 at 9:16 AM, Paul Sandoz <paul.sandoz at> wrote:

> On Apr 27, 2015, at 10:34 PM, Kasper Nielsen <kasperni at> wrote:
> > The other default function I would like to see is stream.toList() (I can
> > live with collectToList) which is short for
> s.collect(Collectors.toList()).
> > 50 % of my terminal functions are s.collect(Collectors.toList()).
> Can you live with a static import and:
>   s.collect(toList())
> ? which is rather close to "collectToList".
> When designing j.u,s.Stream we made a conscious decision to not bind it to
> j.u collection types. A Stream could be integrated with other forms of
> collections (e.g. GS Collections).

First, if you are using any kind of modern IDE you have some kind of
intelligent completion which will suggest collectToList the moment you
press the 'c' in stream.c...
The other one you have to create an additional import, and invoke a static
method (Yes I know most IDEs makes this easy as well)
But we are still talking about something like 1 second vs 5 seconds.

Second, s.collect(toList()) is just not naturally for most users. Sure
readers on this list understands how the collect method works. But I don't
think many novice/intermediate users will.

Third, Yes there are a lot of different collections that a stream can be
integrated with. But we are talking about roughly 50 % of the usage.

Fourth, this hasn't actually anything to do with ease of use but
performance. But I have a very fast stream implementation where I would
like to provide a fast (and easy) way to return the stream elements as a
list. This is mainly in situations where I know the number of elements in
the result (which is quite often if you don't use filters). By having a
toList() method I can implement, I can avoid the array list resizings in
This is actually also why I would prefer if it was called toList() and not
collectToList() as I think it is implementation detail how the list
generation is done.

- Kasper

More information about the core-libs-dev mailing list