RFR JDK-8011426: java.util collection Spliterator implementations

[Mike Duigou]

I went back and started again with the 8010096 webrev.

Spliterators::

- some implementations are private and some are package private. All package private?

List/Set/Iterator/SortedSet::

- Include the same interface level @implSpec warning as Collection?

Spliterator::

- "<p>Spliterators also report ..." You may want to avoid the plural form since there's also a class of that name.

Spliterator.NONNULL - "This applies, for example, to ...". I might like the name Spliterator.NONULLS better.

Spliterator.IMMUTABLE - this name doesn't quite capture what's allowed and what's prohibited. An Arrays.asList() list is IMMUTABLE but elements can still be replaced in place. Collections.unmodifiableList(Array.asList(..)) is entirely immutable. Is the distinction ever important?

- I guess the issue is that some of the flags describe characteristics of the source and some describe characteristics of the elements.

- "A diagnostic warning that boxing of primitives values is occurring of can be requested by setting the boolean system property {@code org.openjdk.java.util.stream.tripwire} is to {@code true}."

- Neither forEachREmaining on Iterator or tryAdvance on Spliterator say whether it's possible (or advisable) to continue advancing following an exception being thrown. Will calling again continue with the next element? The same element? Unspecified? Is calling again after an exception prohibited?

- getExactSizeIfKnown() - use hasCharacteristics?

- The note in CONCURRENT "Such a Spliterator is
     * inconsistent and no guarantees can be made about any computation using
     * that Spliterator." Is this necessary or just confusing. Users won't encounter this.

- Same with the similar note in SUBSIZED. 

Mike



On Apr 10 2013, at 06:50 , Paul Sandoz wrote:

> Hi,
> 
> Following up from JDK-8010096 [1] here is a webrev for spliterator implementations of collection classes in java.util:
> 
>  http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8011426/webrev/
> 
> This is dependent on [1].
> 
> --
> 
> Note that for some reason the webrev script creates the jdk changeset file for my complete hg patch queue and not from the revision i specify. Anyone know how to change that?
> 
> Paul.
> 
> 
> [1] http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/