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...
Regards, Peter
On 06/29/2013 02:58 AM, Henry Jen wrote:
Hi,
Please review the webrev that add concat static method to Stream and
primitive Streams.
http://cr.openjdk.java.net/~henryjen/ccc/8015315.0/webrev/
Cheers,
Henry
