RFR: 8180352: Add Stream.toList() method

Brian Goetz brian.goetz at oracle.com
Tue Nov 3 19:54:57 UTC 2020


>> 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.)  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.)

Please, can we stop having this same tired "I hate nulls, let's find a 
new way to punish people who like them" discussion for every single 
feature?



More information about the core-libs-dev mailing list