842 * <p>The collection is backed by the map, so changes to the map are
843 * reflected in the collection, and vice-versa. If the map is
844 * modified while an iteration over the collection is in progress
845 * (except through the iterator's own {@code remove} operation),
846 * the results of the iteration are undefined. The collection
847 * supports element removal, which removes the corresponding
848 * mapping from the map, via the {@code Iterator.remove},
849 * {@code Collection.remove}, {@code removeAll},
850 * {@code retainAll} and {@code clear} operations. It does not
851 * support the {@code add} or {@code addAll} operations.
852 */
853 public Collection<V> values() {
854 Collection<V> vs = values;
855 return (vs != null) ? vs : (values = new Values());
856 }
857
858 /**
859 * Returns a {@link Set} view of the mappings contained in this map.
860 *
861 * <p>The set's iterator returns the entries in ascending key order. The
862 * sets's spliterator is
863 * <em><a href="Spliterator.html#binding">late-binding</a></em>,
864 * <em>fail-fast</em>, and additionally reports {@link Spliterator#SORTED} and
865 * {@link Spliterator#ORDERED} with an encounter order that is ascending key
866 * order.
867 *
868 * <p>The set is backed by the map, so changes to the map are
869 * reflected in the set, and vice-versa. If the map is modified
870 * while an iteration over the set is in progress (except through
871 * the iterator's own {@code remove} operation, or through the
872 * {@code setValue} operation on a map entry returned by the
873 * iterator) the results of the iteration are undefined. The set
874 * supports element removal, which removes the corresponding
875 * mapping from the map, via the {@code Iterator.remove},
876 * {@code Set.remove}, {@code removeAll}, {@code retainAll} and
877 * {@code clear} operations. It does not support the
878 * {@code add} or {@code addAll} operations.
879 */
880 public Set<Map.Entry<K,V>> entrySet() {
881 EntrySet es = entrySet;
882 return (es != null) ? es : (entrySet = new EntrySet());
2626 return sm.keySpliterator();
2627 }
2628
2629 final Spliterator<K> keySpliterator() {
2630 return new KeySpliterator<>(this, null, null, 0, -1, 0);
2631 }
2632
2633 final Spliterator<K> descendingKeySpliterator() {
2634 return new DescendingKeySpliterator<>(this, null, null, 0, -2, 0);
2635 }
2636
2637 /**
2638 * Base class for spliterators. Iteration starts at a given
2639 * origin and continues up to but not including a given fence (or
2640 * null for end). At top-level, for ascending cases, the first
2641 * split uses the root as left-fence/right-origin. From there,
2642 * right-hand splits replace the current fence with its left
2643 * child, also serving as origin for the split-off spliterator.
2644 * Left-hands are symmetric. Descending versions place the origin
2645 * at the end and invert ascending split rules. This base class
2646 * is non-commital about directionality, or whether the top-level
2647 * spliterator covers the whole tree. This means that the actual
2648 * split mechanics are located in subclasses. Some of the subclass
2649 * trySplit methods are identical (except for return types), but
2650 * not nicely factorable.
2651 *
2652 * Currently, subclass versions exist only for the full map
2653 * (including descending keys via its descendingMap). Others are
2654 * possible but currently not worthwhile because submaps require
2655 * O(n) computations to determine size, which substantially limits
2656 * potential speed-ups of using custom Spliterators versus default
2657 * mechanics.
2658 *
2659 * To boostrap initialization, external constructors use
2660 * negative size estimates: -1 for ascend, -2 for descend.
2661 */
2662 static class TreeMapSpliterator<K,V> {
2663 final TreeMap<K,V> tree;
2664 TreeMap.Entry<K,V> current; // traverser; initially first node in range
2665 TreeMap.Entry<K,V> fence; // one past last, or null
2666 int side; // 0: top, -1: is a left split, +1: right
|
842 * <p>The collection is backed by the map, so changes to the map are
843 * reflected in the collection, and vice-versa. If the map is
844 * modified while an iteration over the collection is in progress
845 * (except through the iterator's own {@code remove} operation),
846 * the results of the iteration are undefined. The collection
847 * supports element removal, which removes the corresponding
848 * mapping from the map, via the {@code Iterator.remove},
849 * {@code Collection.remove}, {@code removeAll},
850 * {@code retainAll} and {@code clear} operations. It does not
851 * support the {@code add} or {@code addAll} operations.
852 */
853 public Collection<V> values() {
854 Collection<V> vs = values;
855 return (vs != null) ? vs : (values = new Values());
856 }
857
858 /**
859 * Returns a {@link Set} view of the mappings contained in this map.
860 *
861 * <p>The set's iterator returns the entries in ascending key order. The
862 * set's spliterator is
863 * <em><a href="Spliterator.html#binding">late-binding</a></em>,
864 * <em>fail-fast</em>, and additionally reports {@link Spliterator#SORTED} and
865 * {@link Spliterator#ORDERED} with an encounter order that is ascending key
866 * order.
867 *
868 * <p>The set is backed by the map, so changes to the map are
869 * reflected in the set, and vice-versa. If the map is modified
870 * while an iteration over the set is in progress (except through
871 * the iterator's own {@code remove} operation, or through the
872 * {@code setValue} operation on a map entry returned by the
873 * iterator) the results of the iteration are undefined. The set
874 * supports element removal, which removes the corresponding
875 * mapping from the map, via the {@code Iterator.remove},
876 * {@code Set.remove}, {@code removeAll}, {@code retainAll} and
877 * {@code clear} operations. It does not support the
878 * {@code add} or {@code addAll} operations.
879 */
880 public Set<Map.Entry<K,V>> entrySet() {
881 EntrySet es = entrySet;
882 return (es != null) ? es : (entrySet = new EntrySet());
2626 return sm.keySpliterator();
2627 }
2628
2629 final Spliterator<K> keySpliterator() {
2630 return new KeySpliterator<>(this, null, null, 0, -1, 0);
2631 }
2632
2633 final Spliterator<K> descendingKeySpliterator() {
2634 return new DescendingKeySpliterator<>(this, null, null, 0, -2, 0);
2635 }
2636
2637 /**
2638 * Base class for spliterators. Iteration starts at a given
2639 * origin and continues up to but not including a given fence (or
2640 * null for end). At top-level, for ascending cases, the first
2641 * split uses the root as left-fence/right-origin. From there,
2642 * right-hand splits replace the current fence with its left
2643 * child, also serving as origin for the split-off spliterator.
2644 * Left-hands are symmetric. Descending versions place the origin
2645 * at the end and invert ascending split rules. This base class
2646 * is non-committal about directionality, or whether the top-level
2647 * spliterator covers the whole tree. This means that the actual
2648 * split mechanics are located in subclasses. Some of the subclass
2649 * trySplit methods are identical (except for return types), but
2650 * not nicely factorable.
2651 *
2652 * Currently, subclass versions exist only for the full map
2653 * (including descending keys via its descendingMap). Others are
2654 * possible but currently not worthwhile because submaps require
2655 * O(n) computations to determine size, which substantially limits
2656 * potential speed-ups of using custom Spliterators versus default
2657 * mechanics.
2658 *
2659 * To boostrap initialization, external constructors use
2660 * negative size estimates: -1 for ascend, -2 for descend.
2661 */
2662 static class TreeMapSpliterator<K,V> {
2663 final TreeMap<K,V> tree;
2664 TreeMap.Entry<K,V> current; // traverser; initially first node in range
2665 TreeMap.Entry<K,V> fence; // one past last, or null
2666 int side; // 0: top, -1: is a left split, +1: right
|