Return types array/list/stream [was: API question for point lambdafication]

Brian Goetz brian.goetz at
Wed Feb 20 08:52:28 PST 2013

I don't want to risk taking it too in the other direction, but I do 
think the points in favor of Stream are applicable in a lot of 
situations.  But as always, it requires some analysis about what you 
expect people to DO with the result.

On 2/20/2013 11:46 AM, Michael Nascimento wrote:
> Given your reasoning, shouldn't the default be Stream from now on?
> Regards,
> Michael
> On Wed, Feb 20, 2013 at 1:35 PM, Brian Goetz <brian.goetz at> wrote:
>>> My preference would be as folows:
>>> - only use array as a return type to match other methods in the same type
>>> - prefer List to Set or Collection
>>> - prefer Stream to Iterator and Enumeration (and probably Iterable)
>>> - prefer List to Stream for small/bounded data sets
>>> Thus, on the last point, I would argue that String.splitAsStream() is
>>> wrong, and should be String.splitToList().  (As a side note, with my
>>> general "arrays are bad" hat on, returning an array here was another
>>> bad choice)
>>> Users wanting a stream can easily get it from the list. The reverse is
>>> not so true, and almost certainly more wasteful.
>> This ignores a significant consideration -- List requires buffering all
>> the matches before any work can be done, whereas Stream is lazy.  What
>> if the List is potentially huge (or infinite)?  What if you're only
>> going to look at the first few?  What if producing elements is
>> expensive?  What if you have an expensive operation to perform on the
>> results, and want to do so in parallel?  In all of these cases,
>> preferring List over Stream gives up significant performance
>> opportunities.  And, constructing lists is likely to be more expensive
>> than constructing streams.
>> The argument that we should "prefer List to Stream because you can
>> always get a stream from a list" is too simplistic.
>> Regex parsing is a good example of where you might want a stream rather
>> than a list, as you might well not consume all the matches.

More information about the lambda-dev mailing list