java.lang.ObjectThis class consists exclusively of static methods that operate on or return collections. It contains polymorphic algorithms that operate on collections, "wrappers", which return a new collection backed by a specified collection, and a few other odds and ends.java.util.Collections
The methods of this class all throw a NullPointerException if the collections or class objects provided to them are null.
The documentation for the polymorphic algorithms contained in this class generally includes a brief description of the implementation. Such descriptions should be regarded as implementation notes, rather than parts of the specification. Implementors should feel free to substitute other algorithms, so long as the specification itself is adhered to. (For example, the algorithm used by sort does not have to be a mergesort, but it does have to be stable.)
The "destructive" algorithms contained in this class, that is, the algorithms that modify the collection on which they operate, are specified to throw UnsupportedOperationException if the collection does not support the appropriate mutation primitive(s), such as the set method. These algorithms may, but are not required to, throw this exception if an invocation would have no effect on the collection. For example, invoking the sort method on an unmodifiable list that is already sorted may or may not throw UnsupportedOperationException.
This class is a member of the Java Collections Framework.
Josh
- BlochNeal
- Gafter1.2
- Nested Class Summary: | ||
---|---|---|
static class | Collections.UnmodifiableCollection | |
static class | Collections.UnmodifiableSet | |
static class | Collections.UnmodifiableSortedSet | |
static class | Collections.UnmodifiableList | |
static class | Collections.UnmodifiableRandomAccessList | |
static class | Collections.UnmodifiableSortedMap | |
static class | Collections.SynchronizedCollection | |
static class | Collections.SynchronizedSet | |
static class | Collections.SynchronizedSortedSet | |
static class | Collections.SynchronizedList | |
static class | Collections.SynchronizedRandomAccessList | |
static class | Collections.SynchronizedSortedMap | |
static class | Collections.CheckedCollection | |
static class | Collections.CheckedSet | |
static class | Collections.CheckedSortedSet | |
static class | Collections.CheckedList | |
static class | Collections.CheckedRandomAccessList | |
static class | Collections.CheckedSortedMap | |
static class | Collections.AsLIFOQueue |
Field Summary | ||
---|---|---|
public static final Set | EMPTY_SET | The empty set (immutable). This set is serializable.
|
public static final List | EMPTY_LIST | The empty list (immutable). This list is serializable.
|
public static final Map | EMPTY_MAP | The empty map (immutable). This map is serializable.
|
Methods from java.lang.Object: |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Method from java.util.Collections Detail: |
---|
When elements are specified individually, this method provides a convenient way to add a few elements to an existing collection: Collections.addAll(flavors, "Peaches 'n Plutonium", "Rocky Racoon"); |
Each method invocation on the queue returned by this method results in exactly one method invocation on the backing deque, with one exception. The addAll method is implemented as a sequence of addFirst invocations on the backing deque. |
This method runs in log(n) time for a "random access" list (which provides near-constant-time positional access). If the specified list does not implement the RandomAccess interface and is large, this method will do an iterator-based binary search that performs O(n) link traversals and O(log n) element comparisons. |
This method runs in log(n) time for a "random access" list (which provides near-constant-time positional access). If the specified list does not implement the RandomAccess interface and is large, this method will do an iterator-based binary search that performs O(n) link traversals and O(log n) element comparisons. |
The generics mechanism in the language provides compile-time (static) type checking, but it is possible to defeat this mechanism with unchecked casts. Usually this is not a problem, as the compiler issues warnings on all such unchecked operations. There are, however, times when static type checking alone is not sufficient. For example, suppose a collection is passed to a third-party library and it is imperative that the library code not corrupt the collection by inserting an element of the wrong type. Another use of dynamically typesafe views is debugging. Suppose a program fails with a {@code ClassCastException}, indicating that an incorrectly typed element was put into a parameterized collection. Unfortunately, the exception can occur at any time after the erroneous element is inserted, so it typically provides little or no information as to the real source of the problem. If the problem is reproducible, one can quickly determine its source by temporarily modifying the program to wrap the collection with a dynamically typesafe view. For example, this declaration: {@code Collectionmay be replaced temporarily by this one: {@code CollectionRunning the program again will cause it to fail at the point where an incorrectly typed element is inserted into the collection, clearly identifying the source of the problem. Once the problem is fixed, the modified declaration may be reverted back to the original. The returned collection does not pass the hashCode and equals operations through to the backing collection, but relies on {@code Object}'s {@code equals} and {@code hashCode} methods. This is necessary to preserve the contracts of these operations in the case that the backing collection is a set or a list. The returned collection will be serializable if the specified collection is serializable. Since {@code null} is considered to be a value of any reference type, the returned collection permits insertion of null elements whenever the backing collection does. |
A discussion of the use of dynamically typesafe views may be found in the documentation for the checkedCollection method. The returned list will be serializable if the specified list is serializable. Since {@code null} is considered to be a value of any reference type, the returned list permits insertion of null elements whenever the backing list does. |
Assuming a map contains no incorrectly typed keys or values prior to the time a dynamically typesafe view is generated, and that all subsequent access to the map takes place through the view (or one of its collection views), it is guaranteed that the map cannot contain an incorrectly typed key or value. A discussion of the use of dynamically typesafe views may be found in the documentation for the checkedCollection method. The returned map will be serializable if the specified map is serializable. Since {@code null} is considered to be a value of any reference type, the returned map permits insertion of null keys or values whenever the backing map does. |
A discussion of the use of dynamically typesafe views may be found in the documentation for the checkedCollection method. The returned set will be serializable if the specified set is serializable. Since {@code null} is considered to be a value of any reference type, the returned set permits insertion of null elements whenever the backing set does. |
Assuming a map contains no incorrectly typed keys or values prior to the time a dynamically typesafe view is generated, and that all subsequent access to the map takes place through the view (or one of its collection views), it is guaranteed that the map cannot contain an incorrectly typed key or value. A discussion of the use of dynamically typesafe views may be found in the documentation for the checkedCollection method. The returned map will be serializable if the specified map is serializable. Since {@code null} is considered to be a value of any reference type, the returned map permits insertion of null keys or values whenever the backing map does. |
A discussion of the use of dynamically typesafe views may be found in the documentation for the checkedCollection method. The returned sorted set will be serializable if the specified sorted set is serializable. Since {@code null} is considered to be a value of any reference type, the returned sorted set permits insertion of null elements whenever the backing sorted set does. |
This method runs in linear time. |
Care must be exercised if this method is used on collections that do not comply with the general contract for {@code Collection}. Implementations may elect to iterate over either collection and test for containment in the other collection (or to perform any equivalent computation). If either collection uses a nonstandard equality test (as does a SortedSet whose ordering is not compatible with equals, or the key set of an IdentityHashMap ), both collections must use the same nonstandard equality test, or the result of this method is undefined. Care must also be exercised when using collections that have restrictions on the elements that they may contain. Collection implementations are allowed to throw exceptions for any operation involving elements they deem ineligible. For absolute safety the specified collections should contain only elements which are eligible elements for both collections. Note that it is permissible to pass the same collection in both parameters, in which case the method will return {@code true} if and only if the collection is empty. |
Implementations of this method are permitted, but not required, to return the same object from multiple invocations. |
Implementations of this method are permitted, but not required, to return the same object from multiple invocations. |
This example illustrates the type-safe way to obtain an empty list: List<String> s = Collections.emptyList();Implementation note: Implementations of this method need not create a separate List object for each call. Using this method is likely to have comparable cost to using the like-named field. (Unlike this method, the field does not provide type safety.) |
Implementations of this method are permitted, but not required, to return the same object from multiple invocations. |
This example illustrates the type-safe way to obtain an empty set: Map<String, Date> s = Collections.emptyMap();Implementation note: Implementations of this method need not create a separate Map object for each call. Using this method is likely to have comparable cost to using the like-named field. (Unlike this method, the field does not provide type safety.) |
This example illustrates the type-safe way to obtain an empty set: Set<String> s = Collections.emptySet();Implementation note: Implementations of this method need not create a separate Set object for each call. Using this method is likely to have comparable cost to using the like-named field. (Unlike this method, the field does not provide type safety.) |
|
|
This method runs in linear time. |
|
This implementation uses the "brute force" technique of scanning over the source list, looking for a match with the target at each location in turn. |
This implementation uses the "brute force" technique of iterating over the source list, looking for a match with the target at each location in turn. |
|
This method iterates over the entire collection, hence it requires time proportional to the size of the collection. |
This method iterates over the entire collection, hence it requires time proportional to the size of the collection. |
This method iterates over the entire collection, hence it requires time proportional to the size of the collection. |
This method iterates over the entire collection, hence it requires time proportional to the size of the collection. |
|
Each method invocation on the set returned by this method results in exactly one method invocation on the backing map or its keySet view, with one exception. The addAll method is implemented as a sequence of put invocations on the backing map. The specified map must be empty at the time this method is invoked, and should not be accessed directly after this method returns. These conditions are ensured if the map is created empty, passed directly to this method, and no reference to the map is retained, as illustrated in the following code fragment: Set<Object> weakHashSet = Collections.newSetFromMap( new WeakHashMap<Object, Boolean>()); |
|
This method runs in linear time. |
Arrays.sort(a, Collections.reverseOrder());sorts the array in reverse-lexicographic (alphabetical) order. The returned comparator is serializable. |
The returned comparator is serializable (assuming the specified comparator is also serializable or {@code null}). |
For example, suppose list comprises [t, a, n, k, s]. After invoking Collections.rotate(list, 1) (or Collections.rotate(list, -4)), list will comprise [s, t, a, n, k]. Note that this method can usefully be applied to sublists to move one or more elements within a list while preserving the order of the remaining elements. For example, the following idiom moves the element at index j forward to position k (which must be greater than or equal to j): Collections.rotate(list.subList(j, k+1), -1);To make this concrete, suppose list comprises [a, b, c, d, e]. To move the element at index 1 (b) forward two positions, perform the following invocation: Collections.rotate(l.subList(1, 4), -1);The resulting list is [a, c, d, b, e]. To move more than one element forward, increase the absolute value of the rotation distance. To move elements backward, use a positive shift distance. If the specified list is small or implements the RandomAccess interface, this implementation exchanges the first element into the location it should go, and then repeatedly exchanges the displaced element into the location it should go until a displaced element is swapped into the first element. If necessary, the process is repeated on the second and successive elements, until the rotation is complete. If the specified list is large and doesn't implement the RandomAccess interface, this implementation breaks the list into two sublist views around index -distance mod size. Then the #reverse(List) method is invoked on each sublist view, and finally it is invoked on the entire list. For a more complete description of both algorithms, see Section 2.3 of Jon Bentley's Programming Pearls (Addison-Wesley, 1986). |
The hedge "approximately" is used in the foregoing description because default source of randomness is only approximately an unbiased source of independently chosen bits. If it were a perfect source of randomly chosen bits, then the algorithm would choose permutations with perfect uniformity. This implementation traverses the list backwards, from the last element up to the second, repeatedly swapping a randomly selected element into the "current position". Elements are randomly selected from the portion of the list that runs from the first element to the current position, inclusive. This method runs in linear time. If the specified list does not implement the RandomAccess interface and is large, this implementation dumps the specified list into an array before shuffling it, and dumps the shuffled array back into the list. This avoids the quadratic behavior that would result from shuffling a "sequential access" list in place. |
This implementation traverses the list backwards, from the last element up to the second, repeatedly swapping a randomly selected element into the "current position". Elements are randomly selected from the portion of the list that runs from the first element to the current position, inclusive. This method runs in linear time. If the specified list does not implement the RandomAccess interface and is large, this implementation dumps the specified list into an array before shuffling it, and dumps the shuffled array back into the list. This avoids the quadratic behavior that would result from shuffling a "sequential access" list in place. |
|
|
|
|
This sort is guaranteed to be stable: equal elements will not be reordered as a result of the sort. The specified list must be modifiable, but need not be resizable. Implementation note: This implementation is a stable, adaptive, iterative mergesort that requires far fewer than n lg(n) comparisons when the input array is partially sorted, while offering the performance of a traditional mergesort when the input array is randomly ordered. If the input array is nearly sorted, the implementation requires approximately n comparisons. Temporary storage requirements vary from a small constant for nearly sorted input arrays to n/2 object references for randomly ordered input arrays. The implementation takes equal advantage of ascending and descending order in its input array, and can take advantage of ascending and descending order in different parts of the same input array. It is well-suited to merging two or more sorted arrays: simply concatenate the arrays and sort the resulting array. The implementation was adapted from Tim Peters's list sort for Python ( TimSort). It uses techiques from Peter McIlroy's "Optimistic Sorting and Information Theoretic Complexity", in Proceedings of the Fourth Annual ACM-SIAM Symposium on Discrete Algorithms, pp 467-474, January 1993. This implementation dumps the specified list into an array, sorts the array, and iterates over the list resetting each element from the corresponding position in the array. This avoids the n2 log(n) performance that would result from attempting to sort a linked list in place. |
This sort is guaranteed to be stable: equal elements will not be reordered as a result of the sort. The specified list must be modifiable, but need not be resizable. Implementation note: This implementation is a stable, adaptive, iterative mergesort that requires far fewer than n lg(n) comparisons when the input array is partially sorted, while offering the performance of a traditional mergesort when the input array is randomly ordered. If the input array is nearly sorted, the implementation requires approximately n comparisons. Temporary storage requirements vary from a small constant for nearly sorted input arrays to n/2 object references for randomly ordered input arrays. The implementation takes equal advantage of ascending and descending order in its input array, and can take advantage of ascending and descending order in different parts of the same input array. It is well-suited to merging two or more sorted arrays: simply concatenate the arrays and sort the resulting array. The implementation was adapted from Tim Peters's list sort for Python ( TimSort). It uses techiques from Peter McIlroy's "Optimistic Sorting and Information Theoretic Complexity", in Proceedings of the Fourth Annual ACM-SIAM Symposium on Discrete Algorithms, pp 467-474, January 1993. This implementation dumps the specified list into an array, sorts the array, and iterates over the list resetting each element from the corresponding position in the array. This avoids the n2 log(n) performance that would result from attempting to sort a linked list in place. |
|
It is imperative that the user manually synchronize on the returned collection when iterating over it: Collection c = Collections.synchronizedCollection(myCollection); ... synchronized (c) { Iterator i = c.iterator(); // Must be in the synchronized block while (i.hasNext()) foo(i.next()); }Failure to follow this advice may result in non-deterministic behavior. The returned collection does not pass the hashCode and equals operations through to the backing collection, but relies on Object's equals and hashCode methods. This is necessary to preserve the contracts of these operations in the case that the backing collection is a set or a list. The returned collection will be serializable if the specified collection is serializable. |
|
It is imperative that the user manually synchronize on the returned list when iterating over it: List list = Collections.synchronizedList(new ArrayList()); ... synchronized (list) { Iterator i = list.iterator(); // Must be in synchronized block while (i.hasNext()) foo(i.next()); }Failure to follow this advice may result in non-deterministic behavior. The returned list will be serializable if the specified list is serializable. |
|
It is imperative that the user manually synchronize on the returned map when iterating over any of its collection views: Map m = Collections.synchronizedMap(new HashMap()); ... Set s = m.keySet(); // Needn't be in synchronized block ... synchronized (m) { // Synchronizing on m, not s! Iterator i = s.iterator(); // Must be in synchronized block while (i.hasNext()) foo(i.next()); }Failure to follow this advice may result in non-deterministic behavior. The returned map will be serializable if the specified map is serializable. |
It is imperative that the user manually synchronize on the returned set when iterating over it: Set s = Collections.synchronizedSet(new HashSet()); ... synchronized (s) { Iterator i = s.iterator(); // Must be in the synchronized block while (i.hasNext()) foo(i.next()); }Failure to follow this advice may result in non-deterministic behavior. The returned set will be serializable if the specified set is serializable. |
|
It is imperative that the user manually synchronize on the returned sorted map when iterating over any of its collection views, or the collections views of any of its subMap, headMap or tailMap views. SortedMap m = Collections.synchronizedSortedMap(new TreeMap()); ... Set s = m.keySet(); // Needn't be in synchronized block ... synchronized (m) { // Synchronizing on m, not s! Iterator i = s.iterator(); // Must be in synchronized block while (i.hasNext()) foo(i.next()); }or: SortedMap m = Collections.synchronizedSortedMap(new TreeMap()); SortedMap m2 = m.subMap(foo, bar); ... Set s2 = m2.keySet(); // Needn't be in synchronized block ... synchronized (m) { // Synchronizing on m, not m2 or s2! Iterator i = s.iterator(); // Must be in synchronized block while (i.hasNext()) foo(i.next()); }Failure to follow this advice may result in non-deterministic behavior. The returned sorted map will be serializable if the specified sorted map is serializable. |
It is imperative that the user manually synchronize on the returned sorted set when iterating over it or any of its subSet, headSet, or tailSet views. SortedSet s = Collections.synchronizedSortedSet(new TreeSet()); ... synchronized (s) { Iterator i = s.iterator(); // Must be in the synchronized block while (i.hasNext()) foo(i.next()); }or: SortedSet s = Collections.synchronizedSortedSet(new TreeSet()); SortedSet s2 = s.headSet(foo); ... synchronized (s) { // Note: s, not s2!!! Iterator i = s2.iterator(); // Must be in the synchronized block while (i.hasNext()) foo(i.next()); }Failure to follow this advice may result in non-deterministic behavior. The returned sorted set will be serializable if the specified sorted set is serializable. |
The returned collection does not pass the hashCode and equals operations through to the backing collection, but relies on Object's equals and hashCode methods. This is necessary to preserve the contracts of these operations in the case that the backing collection is a set or a list. The returned collection will be serializable if the specified collection is serializable. |
The returned list will be serializable if the specified list is serializable. Similarly, the returned list will implement RandomAccess if the specified list does. |
The returned map will be serializable if the specified map is serializable. |
The returned set will be serializable if the specified set is serializable. |
The returned sorted map will be serializable if the specified sorted map is serializable. |
The returned sorted set will be serializable if the specified sorted set is serializable. |
|