|
Java Platform 1.2 Beta 4 |
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
The interfaces that comprise the collection hierarchy are designed to allow manipulation of collections in an implementation-independent fashion. This allows for interoperability among unrelated APIs that take collections as input or return them as output. It reduces the effort in learning new APIs that would otherwise have their own collection interfaces, reduces the effort in designing such APIs, and fosters software reuse.
The collection hierarchy consists of six interfaces, the core collection intefaces. Three of these interfaces, Set, List, and SortedSet are descendants of the Collection interface; they add further constraints on the contracts imposed by the methods in this interface, as well as adding new methods. The other two core collection interfaces, Map and SortedMap, are not descendants of Collection, as they represents mappings rather than true collections.
All of the methods in Collection and the other core interfaces that modify the collection are labeled optional. Some implementations may not perform one or more of these operations, throwing a runtime exception, UnsupportedOperationException, if they are attempted. Implementations should specify in their documentation which optional operations they support. Several terms are introduced to aid in this specification:
Some implementations may restrict what elements (or in the case of Maps, keys and values) may be stored. Possible restrictions include requiring elements to:
All general-purpose Collection implementation classes should provide two "standard" constructors: a void (no arguments) constructor, which creates an empty Collection, and a constructor with a single argument of type Collection, which creates a new Collection with the same elements as its argument. In effect, the latter constructor allows the user to copy any Collection, producing an equivalent Collection of the desired implementation type. Similarly, all general-purpose Map implementations should provide a void (no arguments) constructor and a constructor that takes a single argument of type Map. There is no way to enforce these recommendations (as interfaces cannot contain constructors) but all of the general-purpose Collection and Map implementations in the JDK comply.
Collection implementation classes typically have names of the form <Implementation><Interface>. Set implementations in the JDK include HashSet and TreeSet. List implementations include ArrayList, LinkedList and Vector. Map implementations include HashMap, TreeMap, and Hashtable. (The JDK contains no class that implements Collection directly.)
The new (JDK1.2) general-purpose implementations of the collection interfaces are summarized in the table below:
Implementations | |||||
---|---|---|---|---|---|
Hash Table | Resizable Array | Balanced Tree | Linked List | ||
Interfaces | Set | HashSet
| TreeSet
| ||
List | ArrayList
| LinkedList
| |||
Map | HashMap
| TreeMap
|
All of the new collection implementations have names of the form (<Implementation><Interface>). All are unsynchronized. The Collections class contains static factories that may be used to add synchronization to any unsynchronized collection. All of the new implementations have fail-fast iterators, which detect illegal concurrent modification, and fail quickly and cleanly.
The AbstractCollection, AbstractSet, AbstractList and AbstractSequentialList classes provide skeletal implementations of the core collection interfaces, to minimize the effort required to implement them. The Iterator, ListIterator, Comparable and Comparator interfaces provide the required "infrastructure."
Set
,
List
,
Map
,
SortedSet
,
SortedMap
,
HashSet
,
TreeSet
,
ArrayList
,
LinkedList
,
Vector
,
HashMap
,
TreeMap
,
Hashtable
,
Collections
,
Arrays
,
AbstractCollection
,
AbstractSet
,
AbstractList
,
AbstractSequentialList
,
AbstractMap
,
Iterator
,
ListIterator
,
Comparable
,
Comparator
,
UnsupportedOperationException
,
ConcurrentModificationException
Method Summary | |
boolean | add(Object o)
Ensures that this Collection contains the specified element (optional operation). |
boolean | addAll(Collection c)
Adds all of the elements in the specified Collection to this Collection (optional operation). |
void | clear()
Removes all of the elements from this Collection (optional operation). |
boolean | contains(Object o)
Returns true if this Collection contains the specified element. |
boolean | containsAll(Collection c)
Returns true if this Collection contains all of the elements in the specified Collection. |
boolean | equals(Object o)
Compares the specified Object with this Collection for equality. |
int | hashCode()
Returns the hash code value for this Collection. |
boolean | isEmpty()
Returns true if this Collection contains no elements. |
Iterator | iterator()
Returns an Iterator over the elements in this Collection. |
boolean | remove(Object o)
Removes a single instance of the specified element from this Collection, if it is present (optional operation). |
boolean | removeAll(Collection c)
Removes from this Collection all of its elements that are contained in the specified Collection (optional operation). |
boolean | retainAll(Collection c)
Retains only the elements in this Collection that are contained in the specified Collection (optional operation). |
int | size()
Returns the number of elements in this Collection. |
Object[] | toArray()
Returns an array containing all of the elements in this Collection. |
Object[] | toArray(Object[] a)
Returns an array containing all of the elements in this Collection, whose runtime type is that of the specified array. |
Method Detail |
public int size()
public boolean isEmpty()
public boolean contains(Object o)
e
such that (o==null ? e==null :
o.equals(e))
.
o
- element whose presence in this Collection is to be tested.public Iterator iterator()
public Object[] toArray()
This method acts as bridge between array-based and Collection-based APIs.
public Object[] toArray(Object[] a)
If the Collection fits in the specified array with room to spare (i.e., the array has more elements than the Collection), the element in the array immediately following the end of the collection is set to null. This is useful in determining the length of the Collection only if the caller knows that the Collection does not contain any null elements.)
If this Collection makes any guarantees as to what order its elements are returned by its Iterator, this method must return the elements in the same order.
Like toArray()
, this method acts as bridge between
array-based and Collection-based APIs. Further, this method allows
precise control over the runtime type of the output array, and
may, under certain circumstances, be used to save allocation costs
Suppose l is a List known to contain only strings. The following code can be used to dump the list into a newly allocated array of String:
String[] x = (String[]) v.toArray(new String[0]);
Note that toArray(new Object[0])
is identical in
function to toArray()
.
a
- the array into which the elements of the Collection are to
be stored, if it is big enough; otherwise, a new array of the
same runtime type is allocated for this purpose.public boolean add(Object o)
Collections that support this operation may place limitations on what elements may be added to the Collection. In particular, some Collections will refuse to add null elements, and others will impose restrictions on the type of elements that may be added. Collection classes should clearly specify in their documentation any restrictions on what elements may be added.
If a Collection refuses to add a particular element for any reason other than that it already contains the element, it must throw an exception (rather than returning false). This preserves the invariant that a Collection always contains the specified element after this call returns.
o
- element whose presence in this Collection is to be ensured.public boolean remove(Object o)
e
such that (o==null ? e==null :
o.equals(e))
, if the Collection contains one or more such
elements. Returns true if the Collection contained the specified
element (or equivalently, if the Collection changed as a result of the
call).
o
- element to be removed from this Collection, if present.public boolean containsAll(Collection c)
contains(Object)
public boolean addAll(Collection c)
c
- elements to be inserted into this Collection.add(Object)
public boolean removeAll(Collection c)
c
- elements to be removed from this Collection.remove(Object)
,
contains(Object)
public boolean retainAll(Collection c)
c
- elements to be retained in this Collection.remove(Object)
,
contains(Object)
public void clear()
public boolean equals(Object o)
While Collection adds no stipulations to the general contract for Object.equals, programmers who implement Collection "directly" (in other words, create a class that is a Collection but is not a Set or a List) must exercise care if they choose to override Object.equals. It is not necessary to do so, and the simplest course of action is to rely on Object's implementation, but the implementer may wish to implement a "value comparison" in place of the default "reference comparison." (Lists and Sets mandate such value comparisons.)
The general contract for Object.equals states that equals
must be symmetric (in other words, a.equals(b)
if and only
if b.equals(a)
). The contracts for List.equals and
Set.equals state that Lists are only equal to other Lists, and
Sets to other Sets. Thus, a custom equals method for a Collection
class that implements neither a List nor a Set must return false when
this Collection is compared to any List or Set. (By the same logic,
it is not possible to write a class that correctly implements both the
Set and List interfaces.)
o
- Object to be compared for equality with this Collection.Object.equals(Object)
,
Set.equals(Object)
,
List.equals(Object)
public int hashCode()
c1.equals(c2)
implies that
c1.hashCode()==c2.hashCode()
.Object.hashCode()
,
Object.equals(Object)
|
Java Platform 1.2 Beta 4 |
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |