On Wed, 4 Nov 2020 23:18:29 GMT, Paŭlo Ebermann <github.com+645859+ep...@openjdk.org> wrote:
>> Changes requested by orio...@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. @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. ------------- PR: https://git.openjdk.java.net/jdk/pull/1026
