RFR: 8180352: Add Stream.toList() method

[Aaron Scott-Boddendijk]

 >>> But it can not be immutable too, for the same reason.

>> Nope. The spec of toList() very clearly says: no guarantees as to the
type,
>> mutability, serializability, etc etc of the returned list. That doesn't
mean
>> that every method returning a List added to the JDK after
Collectors::toList
>> must similarly disavow all such guarantees.

>> (In fact, we would be entirely justified to change the behavior of
>> Collectors::toList tomorrow, to match the proposed Stream::toList; the
spec was
>> crafted to preserve this option. We probably won't, because there are
too many
>> programmers who refuse to read the specification, and have baked in the
>> assumption that it returns an ArrayList, and this would likely just be
picking
>> a fight for little good reason, regardless of who is right.)

>I don't understand your argument.
>You know that you can not change the implementation of
Collectors.toList(), and you also know that if there is a method
Stream.toList(), people will replace the calls to
>.collect(Collectors.toList()) by a call to Stream.toList() for the very
same reason but you want the semantics of Stream.toList() to be different
from the semantics of Collectors.toList().

Surely, taking that position, List.of(...) should not have produced an
unmodifiable list since many combinations of creating Lists would not have
produced unmodifiable lists.

In all of the teams I've worked with, through many Java version transitions
(and 3rdparty library version transitions), dealing with the selective
adoption of new APIs is nothing new.

This case is no different, developers will need to identify the cases in
which they can accept the list as unmodifiable and replace those uses of
Collectors.toList() and Collectors.toUnmodifiableList().

And static-analysis will be able to propose some of those replacements for
us.

Does this mean it's more complex than a text-replace, sure. Will there be
mistakes, sure. But are there benefits to the immutability of the API
result? I suggest that's pretty hard to debate against given the risk of a
mistake is an exception rather than bad data outcomes.

Please don't blunt the tool to make it safer for children.

--
Aaron Scott-Boddendijk


On Wed, Nov 4, 2020 at 9:30 AM <forax at univ-mlv.fr> wrote:

> > De: "Brian Goetz" <brian.goetz at oracle.com>
> > À: "Remi Forax" <forax at univ-mlv.fr>
> > Cc: "Stuart Marks" <smarks at openjdk.java.net>, "core-libs-dev"
> > <core-libs-dev at openjdk.java.net>
> > Envoyé: Mardi 3 Novembre 2020 20:54:57
> > Objet: Re: RFR: 8180352: Add Stream.toList() method
>
> >>> There is no value in making users remember which stream methods are
> >>> null-hostile and which are null-tolerant; this is just more accidental
> >>> complexity.
>
> >> I think that ship has sailed a long ago.
> >> Some collectors are null hostile, some are not.
> >> You can make a point that a Collector is technically not the Stream API
> per se.
>
> > Yes, and this is no mere "technical argument". A Collector is a
> collection of
> > behaviors, governed by its own spec. The behaviors passed to stream
> operations,
> > whether they be lambdas passed by the user (`.map(x ->
> x.hopeXIsntNull())`) or
> > collector objects or comparators, are under the control of the user, and
> it is
> > the user's responsibility to pass behaviors which are compatible with
> the data
> > domain -- which the user knows and the streams implementation cannot
> know.
>
> >> Because of that, i don't think we even have the choice of the semantics
> for
> >> Stream.toList(), it has to be the same as
> stream.collect(Collectors.toList()).
>
> > This doesn't remotely follow. (And, if it did, I would likely not even
> support
> > this RFE.)
> It seems you had an issue when replying to my mail, there is a paragraph
> before "Because"
>
> > Let's take a step back,
> > if we introduce a method toList() on Stream it will be used a lot, i
> mean really
> > a lot, to the point where people will change the code from
> > stream.collect(Collectors.toList()) to use stream.toList() instead.
>
> > The spec of Collectors::toList was crafted to disavow pretty much
> anything other
> > than List-hood, in part in anticipation of this addition.
>
> >> But it can not be immutable too, for the same reason.
>
> > Nope. The spec of toList() very clearly says: no guarantees as to the
> type,
> > mutability, serializability, etc etc of the returned list. That doesn't
> mean
> > that every method returning a List added to the JDK after
> Collectors::toList
> > must similarly disavow all such guarantees.
>
> > (In fact, we would be entirely justified to change the behavior of
> > Collectors::toList tomorrow, to match the proposed Stream::toList; the
> spec was
> > crafted to preserve this option. We probably won't, because there are
> too many
> > programmers who refuse to read the specification, and have baked in the
> > assumption that it returns an ArrayList, and this would likely just be
> picking
> > a fight for little good reason, regardless of who is right.)
> I don't understand your argument.
> You know that you can not change the implementation of
> Collectors.toList(), and you also know that if there is a method
> Stream.toList(), people will replace the calls to
> .collect(Collectors.toList()) by a call to Stream.toList() for the very
> same reason but you want the semantics of Stream.toList() to be different
> from the semantics of Collectors.toList().
>
> Rémi
>