On Fri, 6 Nov 2020 03:01:42 GMT, Stuart Marks <sma...@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
