The Collections Framework was first added in Java
1.2. It includes the original Vector,
classes from Java 1.0 and also adds several important classes designed
to make handling of "collections" of objects much easier.
We referred to these collections in Chapter
1: Supplements as object containers (not to be confused
with graphic components containers in Chapters 6 and 7). We do not
have space to devote to a full discussion of all the interfaces
and classes in the Collections Framework, but we do describe some
of the basic functionality. To quote from the online documentation
The collections framework is a unified architecture for representing
and manipulating collections, allowing them to be manipulated
independently of the details of their representation. It reduces
programming effort while increasing performance. It allows for
interoperability among unrelated APIs, reduces effort in designing
and learning new APIs, and fosters software reuse.
How does it do all that? Some of the increased performance
of the Collections Framework comes about because of the use of non-synchronized
versions of some of the original object container classes. For example,
we've already seen the non-synchronized HashMap
class that generally replaces the original Hashtable
class when thread safety is not an issue. There is also a non-synchronized
replacement for Vector
In addition, the Collections Framework includes optimized
high-performance implementations of several useful and important
algorithms and data structures - sorting algorithms for instance.
Since these are provided by the framework, you don't have to write
The Collections Framework adds interfaces for several
new container types. The root interface is Collection,
which represents a group of objects. There are three main sub-interfaces
- Set, List,
is a collection that has no duplicate elements. The order of appearance
of elements in the Set is unspecified and may change.
is an ordered collection such that each element in the list has
a distinct place in the list. An element in a list can be retrieved
by its integer index, somewhat like an array. Most Lists permit
is a Set
stored in such a way that when you iterate through the SortedSet
with an Iterator
(see next section), the elements are returned in ascending "order."
These are interfaces, not concrete classes. The Collections
Framework has several concrete implementations. For example, Stack,
all implement List.
A concrete SortedSet
and a concrete Set
There are several other concrete implementations as well for specialized
purposes. We illustrate only a few of these in this book.
There are two other base interfaces in the Collections
Framework - Map
All maps use key/value pairs, as in the Hashtable
seen above. Other concrete implementations of Map
are the Properties
classes seen earlier. A concrete version
is the TreeMap.
J2SE 5.0 adds the Queue
interface to the Collections Framework, and the LinkedList
class has been retrofitted to implement Queue.
That means you can use a LinkedList
as a plain List
or as a Queue.
Queues are useful for when you need first-in, first-out behavior,
though some queues provide different orderings.
All Collections support add()
methods to insert and remove elements. The Queue
interface adds the preferred offer()
methods. They are functionally equivalent to add()
except for their behavior in exceptional situations. While add()
fails by throwing an unchecked exception if the queue is full, offer()
fails with an exception if the queue is empty while poll()
References & Web Resources
Latest update: Nov. 18, 2004