RFR: 8180352: Add Stream.toList() method

[Stuart Marks]

On Fri, 6 Nov 2020 03:01:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> 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.
>
> @ePaul wrote:
> 
>> The Stream API works just as well with [third party] 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.
> 
> The separation between streams and the java.util Collections Framework is a good design principle, but it isn't an ironclad rule. It's still easy to have streams create instances of other collections libraries using the Collector interface. What's different here is that the Collections Framework has "leaked into" streams a little bit more, so that they're now more interdependent. This doesn't seem to have any disadvantages; it seems unlikely that the Collections Framework will ever be unplugged from the JDK. However, the benefits are that a List is the closest thing we have to an unmodifiable array that also plays well with generics and that can be value-based; these benefits are considerable.

> Simon Roberts wrote:

> This discussion of unmodifiable lists brings me back to the thought that
> there would be good client-side reasons for inserting an UnmodifiableList
> interface as a parent of LIst, not least because all our unmodifiable
> variants from the Collections.unmodifiableList proxy onward fail the Liskov
> substitution test for actually "being contract-fulfilling Lists".

At some point there probably will need to be a long article explaining all the issues here, but at the moment the best writeup I have is this one:

https://stackoverflow.com/a/57926310/1441122

TL;DR there are a few different ways to approach retrofitting something like this, but they all have enough compromises that the net benefits are unclear.

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

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