Add convenience collect methods to the Stream interface

[James Roper]

Just wanted to put my hand up to say that I have had the same experience,
more than 50% of the time that I've used JDK8 streams I've used
.collect(Collectors.toList()).

But, as a counter point, let me speculate that many or most uses of streams
fall into two broad use cases. One is for actual stream processing, where
you aren't necessarily dealing with a stream that is materialized in
memory, where you may want the power of parallel processing, where you
certainly do want multiple stages of the stream processing chained together
rather than having each stage materialize a new collection in memory, and
this is what the stream API was created for. In this case, collecting to a
list is common but not that common, perhaps not common enough to warrant a
convenience method on Stream.

The other broad use case category is to work with Lists and Sets in a
functional programming style. In this case, you simply want to map, filter,
flatMap etc every element in your list/set, and this is where collecting to
a list and set is almost always the terminal operation for a stream.
Although you can use the stream API to do this, I speculate that it wasn't
primarily designed for this, and I think if the JDK wanted to provide first
class support for doing this, there would be better ways to go about it -
for example, by placing map/filter/flatMap methods directly on the
Collection interfaces and returning the collections directly, rather than
having to convert to a stream and back. Going through a stream still has
its advantages (eg, it uses less memory since you don't need to materialize
a new collection between each stage of the processing), but lacks the
convenience that other collection APIs that offer true functional
programming for Java have (eg, vavr, formerly javaslang).

And, if the JDK was to start adding features for functional programming
like that to its collection API, then it may be worth considering other
features, such as persistent collections, that is, collections where
operations such as add/remove aren't destructive, ie, immutable collections
that support efficient (constant time) append/prepend operations that
return a copy of the list. My point is that if the JDK does start to
consider adding functional programming to its collection APIs, a
holistic approach should be taken to work out what things would look like
long term, even if not all of those features are added immediately (or
ever).

On Mon, 10 Dec 2018 at 10:04, Rob Griffin (rgriffin) <Rob.Griffin at quest.com>
wrote:

> Hi,
>
> I have raised an enhancement request (Incident Report 913453) about adding
> some convenience methods to the Stream interface that collect the stream
> and Pallavi Sonal asked me to start a thread here about that.
>
> More than 50% of our Stream collect calls use Collectors.toList() or
> Collectors.toSet() as arguments so I think it would be very handy if the
> Stream interface had default collectToList and collectToList and
> collectToMap methods.
>
> The advantages are:
>         it would be easier to use code completion in IDEs. There are lot
> of classes starting with Collect so finding the Collectors class is a bit
> of a pain.
>         one less method call in what is usually a long chain of calls.
>
> Regards,
>
> Rob Griffin
> Software Analyst, Spotlight on SQL Server
> Quest | R&D
> rob.griffin at quest.com
>
>

-- 
James Roper
Architect, Office of the CTO, Lightbend, Inc.
@jroper <https://twitter.com/jroper>

<https://www.lightbend.com/>