RFR: JDK-8277095 : Empty streams create too many objects

kabutz duke at openjdk.java.net
Mon Nov 15 12:46:30 UTC 2021


On Wed, 10 Nov 2021 07:45:27 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

>> @kabutz I agree that i wouldn't consider it clean code to use a stream like i put into the example. I only brought it up because it might break existing code, since i think streams are expected to be lazy. Interesting to see that they are in fact not lazy in all situations - i put that into my notes.
>
> Edit: actually I think the implementation of `Collection::stream` could simply be changed to:
> 
> 
> default Stream<E> stream() {
>     var spliterator = spliterator();
>     if(spliterator.hasCharacteristics(Spliterator.IMMUTABLE | Spliterator.CONCURRENT) && isEmpty()) {
>         return Stream.empty();
>     }
>     return StreamSupport.stream(spliterator, false);
> }
> 
> 
> Note that the spliterators of methods such as `Collections::emptyList`, `List::of`, `List::copyOf`, `Set::of`, ... currently don't have the `IMMUTABLE` characteristic though, so they should be updated.
> 
> ---
> 
> The Javadoc for [java.util.stream](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/package-summary.html) is clear though:
> 
>> Traversal of the pipeline source does not begin until the terminal operation of the pipeline is executed.
> 
> and further on says:
> 
>> Spliterators for mutable data sources have an additional challenge; timing of binding to the data, since the data could change between the time the spliterator is created and the time the stream pipeline is executed. Ideally, a spliterator for a stream would report a characteristic of IMMUTABLE or CONCURRENT; if not it should be late-binding.
> 
> which explains why the collections in `java.util.concurrent` (whose spliterators have one of those characteristics) need not be late-binding.

Thanks @anthonyvdotbe I believe that would satisfy the lazy binding, and then we should increase the use of the IMMUTABLE characteristic where it makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6275


More information about the core-libs-dev mailing list