RFR: 8015315: Stream.concat methods

[Paul Sandoz]

On Jul 3, 2013, at 11:18 AM, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Henry,
> 
> I think that ConcatSpliterator.characteristics() method is not honoring 
> the spec which says:
> 
>      * Returns a set of characteristics of this Spliterator and its
>      * elements. The result is represented as ORed values from {@link
>      * #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED},
>      * {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT},
>      * {@link #SUBSIZED}. *Repeated calls to {@code characteristics()} on**
> **     * a given spliterator should always return the same result.*
>      *
>      * <p>If a Spliterator reports an inconsistent set of
>      * characteristics (either those returned from a single invocation
>      * or across multiple invocations), no guarantees can be made
>      * about any computation using this Spliterator.
>      *
>      * @return a representation of characteristics
>      */
>     int characteristics();
> 
> 
> The implementation:
> 
>  736         @Override
>  737         public int characteristics() {
>  738             if (beforeSplit) {
>  739                 // Concatenation loses DISTINCT and SORTED characteristics
>  740                 return aSpliterator.characteristics() & bSpliterator.characteristics()
>  741                        & ~(Spliterator.DISTINCT | Spliterator.SORTED
>  742                            | (unsized ? Spliterator.SIZED | Spliterator.SUBSIZED : 0));
>  743             }
>  744             else {
>  745                 return bSpliterator.characteristics();
>  746             }
>  747         }
> 
> 
> ...is such that repeated calls to the method can return different 
> results over time.
> 


> 
> The question is whether the spec. is OK as it is. No constraints are put 
> on the characteristics of the Spliterator returned from the trySplit() 
> method, so why should "this" Spliterator have constant characteristics 
> for the entire lifetime? That is not symmetric. Perhaps the spec. should 
> only constrain characteristics to be constant between two consecutive 
> calls to trySplit() and only allow characteristics to change as a result 
> of trySplit() returning non-null...
> 

Yes, I think that was the general intention. A given spliterator "morphs" into another when it is split.

Many spliterators will change characteristics when split e.g. for maps the top level spliterator will report SIZED, but when split it will not.

I think we can say:

     * {@link #SUBSIZED}.  Repeated calls to {@code characteristics()} on
     * a given spliterator, prior to splitting, should always return the same result.

Paul.