29 |
|
* <i>is</i> well-defined even if its ordering is inconsistent with equals; it |
30 |
|
* just fails to obey the general contract of the <tt>Set</tt> interface. |
31 |
|
* |
32 |
< |
* <p><b>Note that this implementation is not synchronized.</b> If multiple |
33 |
< |
* threads access a set concurrently, and at least one of the threads modifies |
34 |
< |
* the set, it <i>must</i> be synchronized externally. This is typically |
35 |
< |
* accomplished by synchronizing on some object that naturally encapsulates |
36 |
< |
* the set. If no such object exists, the set should be "wrapped" using the |
37 |
< |
* <tt>Collections.synchronizedSet</tt> method. This is best done at creation |
38 |
< |
* time, to prevent accidental unsynchronized access to the set: <pre> |
39 |
< |
* SortedSet s = Collections.synchronizedSortedSet(new TreeSet(...)); |
40 |
< |
* </pre> |
32 |
> |
* <p><strong>Note that this implementation is not synchronized.</strong> |
33 |
> |
* If multiple threads access a tree set concurrently, and at least one |
34 |
> |
* of the threads modifies the set, it <i>must</i> be synchronized |
35 |
> |
* externally. This is typically accomplished by synchronizing on some |
36 |
> |
* object that naturally encapsulates the set. |
37 |
> |
* If no such object exists, the set should be "wrapped" using the |
38 |
> |
* {@link Collections#synchronizedSortedSet Collections.synchronizedSortedSet} |
39 |
> |
* method. This is best done at creation time, to prevent accidental |
40 |
> |
* unsynchronized access to the set: <pre> |
41 |
> |
* SortedSet s = Collections.synchronizedSortedSet(new TreeSet(...));</pre> |
42 |
|
* |
43 |
|
* <p>The iterators returned by this class's <tt>iterator</tt> method are |
44 |
|
* <i>fail-fast</i>: if the set is modified at any time after the iterator is |
69 |
|
* @see HashSet |
70 |
|
* @see Comparable |
71 |
|
* @see Comparator |
71 |
– |
* @see Collections#synchronizedSortedSet(SortedSet) |
72 |
|
* @see TreeMap |
73 |
|
* @since 1.2 |
74 |
|
*/ |