RFR JDK-8011426: java.util collection Spliterator implementations

[Paul Sandoz]

On Apr 19, 2013, at 6:52 AM, Mike Duigou <mike.duigou at oracle.com> wrote:

> I reversed this change :
> 
> -final Collection<? extends E> c;
> -
> +        final Collection<E> c;
> 
> 
> in Collections.UnmodifiableCollection instead opting or casts in the forEach and spliterator Methods.
> 

OK, i prefer the former but i ain't gonna argue this one :-)


> 
> - I wonder if it's worth it to have the NONNULL characteristic change in Collections::singletonSpliterator depending on element. 
> 

My preference is to be accurate if it is cheap to do.


> LinkedHashMap::
> 
> - needs an overridden spliterator providing ORDERED for it's entry set. (I can do this tomorrow if needed).
> 

Right, the key/value/entry collections all have an encounter order. 

Note that one cannot leverage the HashMap spliterator implementations, we need to create a spliterator from the collection (basically delayed use of the collection's iterator), hence the following check in HashMap:

            if (HashMap.this.getClass() == HashMap.class)

Doing something more optimal for LinkedHashMap would require a lot more work.


> PriorityQueue::
> 
> - I am surprised the spliterator is not ORDERED.
> 

Yes, that surprised me at first.  Guarantees on order are only made for the head, plus the order is not stable for two values that tie for the least value.

Paul.