RFR JDK-8011426: java.util collection Spliterator implementations
paul.sandoz at oracle.com
Fri Apr 19 09:36:32 UTC 2013
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.
> - 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.
> - 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.
More information about the core-libs-dev