On Wed, 10 Nov 2021 07:45:27 GMT, Anthony Vanelverdinghe
<d...@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
