/** * A {@link NavigableSet} implementation based on a {@link TreeMap}. * The elements are ordered using their {@linkplain Comparable natural * ordering}, or by a {@link Comparator} provided at set creation * time, depending on which constructor is used. * *
This implementation provides guaranteed log(n) time cost for the basic
* operations ({@code add}, {@code remove} and {@code contains}).
*
*
Note that the ordering maintained by a set (whether or not an explicit * comparator is provided) must beconsistent with equalsif it is to * correctly implement the {@code Set} interface. (See {@code Comparable} * or {@code Comparator} for a precise definition ofconsistent with
* equals.) This is so because the {@code Set} interface is defined in * terms of the {@code equals} operation, but a {@code TreeSet} instance * performs all element comparisons using its {@code compareTo} (or * {@code compare}) method, so two elements that are deemed equal by this method * are, from the standpoint of the set, equal. The behavior of a set *iswell-defined even if its ordering is inconsistent with equals; it * just fails to obey the general contract of the {@code Set} interface. * *
Note that this implementation is not synchronized.* If multiple threads access a tree set concurrently, and at least one * of the threads modifies the set, itmustbe synchronized * externally. This is typically accomplished by synchronizing on some * object that naturally encapsulates the set. * If no such object exists, the set should be "wrapped" using the * {@link Collections#synchronizedSortedSet Collections.synchronizedSortedSet} * method. This is best done at creation time, to prevent accidental * unsynchronized access to the set:
* SortedSet s = Collections.synchronizedSortedSet(new TreeSet(...));
* *
The iterators returned by this class's {@code iterator} method are *fail-fast: if the set is modified at any time after the iterator is * created, in any way except through the iterator's own {@code remove} * method, the iterator will throw a {@link ConcurrentModificationException}. * Thus, in the face of concurrent modification, the iterator fails quickly * and cleanly, rather than risking arbitrary, non-deterministic behavior at * an undetermined time in the future. * *
Note that the fail-fast behavior of an iterator cannot be guaranteed * as it is, generally speaking, impossible to make any hard guarantees in the * presence of unsynchronized concurrent modification. Fail-fast iterators * throw {@code ConcurrentModificationException} on a best-effort basis. * Therefore, it would be wrong to write a program that depended on this * exception for its correctness:the fail-fast behavior of iterators
* should be used only to detect bugs.* *
This class is a member of the * * Java Collections Framework. * * @param the type of elements maintained by this set
*
* @author Josh Bloch
* @see Collection
* @see Set
* @see HashSet
* @see Comparable
* @see Comparator
* @see TreeMap
* @since 1.2
*/