On Apr 19, 2013, at 6:52 AM, Mike Duigou <[email protected]> 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.
