RFR 8169808 Stream returning methods should specify if they are late binding

[Martin Buchholz]

On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but
> probably they should, given the implementation effort we've already done to
> make it so.
> >
>
> Late-binding really only applies to spliterators not reporting IMMUTABLE
> or CONCURRENT. What did you have in mind?
>
>
j.u.c. Spliterators like in ConcurrentLinkedDeque ...

https://bugs.openjdk.java.net/browse/JDK-8169739?focusedCommentId=14022987&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14022987

... have extra complexity to support the idea that they are never surely
exhausted when created, even if the collection happens to have no elements
at that point.  I was hoping you would have opinions on that (I gave up on
making that change).

We make an effort to provide this behavior, but we don't promise it to our
users!

Let's look at the definition:
"""A late-binding Spliterator binds to the source of elements at the point
of first traversal ..."""
That applies equally well to concurrent and non-concurrent spliterators!
Why don't we specify late-binding for those concurrent spliterators that in
fact implement it, or abandon implementing it?