RFR: 8180352: Add Stream.toList() method

[forax at univ-mlv.fr]

> De: "Alan Snyder" <fishgarage at cbfiddle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Simon Roberts" <simon at dancingcloudservices.com>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 6 Novembre 2020 18:55:40
> Objet: Re: RFR: 8180352: Add Stream.toList() method
Hi Alan, 

>>> 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
>> On Nov 6, 2020, at 1:14 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>> This question is asked at least every six months since 1998
>> [
>> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1
>> |
>> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1
>> ]

> The question that Simon asked is not exactly the question that is answered in
> this link.

> The question of whether List should be a subtype of (some kind of) ImmutableList
> is answered in
> Stuart’s stack overflow answer ( [ https://stackoverflow.com/a/57926310/1441122
> | https://stackoverflow.com/a/57926310/1441122 ] ). The answer
> is that it should not.

> The question answered in the link is basically a straw man: why not capture
> every conceivable
> semantic distinction in the collections type system. And the answer is, not
> surprisingly, that
> there would be way too many types.

It's a strawman but the effect is real, the more interfaces you have the less you can reuse code because the code is written with the wrong interface for your use case. 

> But a question that deserves ongoing review is whether Java should support
> immutable collections
> using a separate type hierarchy. In other words, Immutable List would not be a
> subtype of List
> and List would not be a subtype of Immutable List. The linked answer says:
> " Adding this support to the type hierarchy requires four more interfaces.” Four
> additional
> interfaces sounds like a small cost for a significant benefit. As Java evolves
> to better support
> functional programming styles, immutable collections seems like an obvious next
> step.

> Much could be written, and probably has been, about the disadvantages of basing
> the
> collections framework on mutable collections. Let me just remark that in
> addition to the
> already mentioned UnsupportedOperationException, there is also the more subtle
> ConcurrentModificationException, both of which would be absent in fully
> immutable collections.

Following the same reasoning, you can say that having interfaces saying that collections are null hostile is even more important because it alleviate the issue with NullPointerException. 

> The lack of subtyping between List and ImmutableList is not terrible. Arrays
> coexist with
> Lists with no subtyping relationship. java.io.File coexists with
> java.nio.filePath with no
> subtyping relationship. It means that explicit conversions are required between
> List and
> ImmutableList. Extra copying may be needed, but there are tricks for reducing
> copying, and the
> need for defensive copying is removed.

Array vs List is not something we can be very proud of, by example in java.lang.invoke, we have several methods that are duplicated only because of this dichotomy. 
File vs Path is less an issue because it's between implementation classes, not interfaces, anyway, you still have a number of methods inside java.io/java.nio that are duplicated. 

Anyway, I don't think we can *all* agree about how a collection API should be implemented because it is equivalent to answering to the question what you want to be part of the type system and what you want to be runtime exceptions. 
With that in minde, Java is in the middle between Clojure and Scala. 

> Alan

Rémi