RFR: 8180352: Add Stream.toList() method

[Paŭlo Ebermann]

On Wed, 4 Nov 2020 08:53:23 GMT, Zheka Kozlov <github.com+761899+orionll at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> Changes requested by orionll at github.com (no known OpenJDK username).

Looking at the linked issue, I see [this comment from Rémi Forax](https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14171626&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14171626):

> Please talk with Brian about this change because it nulls a property of the Stream API we (the lambda-util group) have take time to keep.
The whole Stream API doesn't depends on the Collection API, [...] so the Stream API can be easily integrated with other collection API if in the future we want by example add a persistent collection API with no link with java.util.List.

That's an argument I can understand – as is, the Stream API works just as well with collections from e.g. Scala's or Kotlin's (or Ceylon's) collection libraries instead of the java.util ones, just using different collectors. Adding a method which directly returns a java.util.List somewhat couples it to the Java Collection API.

Now this was mentioned two and a half year ago. Did something change which made this consideration irrelevant? I would expect at least some mention of it in the discussion here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026