Loose end: spliterator() and stream() methods on Iterable

Brian Goetz brian.goetz at oracle.com
Tue Jun 25 08:27:39 PDT 2013

As I try to specify even this small addition, I'm still not sure :(

The default implementation -- which is just

   return Spliterators.spliteratorUnknownSize(iterator(), 0);

should almost always be overriden.  It has crappy parallelism, doesn't 
know its size, doesn't know any other spliterator characteristics, and 
is early-binding -- the "grand slam" of bad spliterators.

The downside is that people will not override spliterator() and result 
in bad streams.  The upside is that then Iterable *has* a spliterator() 
method, which reduces the effort for *clients* to make streams out of 

Here's what I've got so far:

      * Creates a {@link Spliterator} over the elements described by this
      * {@code Iterable}.
      * @implSpec
      * <p>The default implementation should almost always be 
overridden.  The
      * spliterator returned by the default implementation has poor 
      * characteristics, is unsized (and does not report any other 
      * characteristics), and is <em><a 
      * Implementating classes can nearly always provide a better 
      * The returned spliterator inherits the <em>fail-fast</em> 
properties of the
      * collection's iterator.
      * @return a {@code Spliterator} over the elements described by this
      * {@code Iterable}.
      * @since 1.8
     default Spliterator<T> spliterator() {
         return Spliterators.spliteratorUnknownSize(iterator(), 0);

On 6/25/2013 6:39 AM, Paul Sandoz wrote:
> On Jun 24, 2013, at 11:41 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> On 06/24/2013 09:40 PM, Brian Goetz wrote:
>>> After further thought, I think what this means is that we can move spliterator() up to Iterable, but not stream().  The reason for this is that some classes that implement Iterable<Integer> might prefer that their stream() method return an IntStream, not be forced into a Stream<Integer>.  So putting stream() too high up in the hierarchy forecloses on this.
>> I agree,
> +1
> Paul.
>> Spliterator.OfInt is a Spliterator but IntStream is not a Stream.
>> Rémi

More information about the lambda-libs-spec-experts mailing list