Commons-Collections and the Java Collections Framework provide a wide variety of collections to choose from. This choice can be bewildering, so this document seeks to help you choose.
Do you want to store a map of key-value pairs?
Then use a Map.
For example you could decode country codes, where 'FR' maps to 'France' and 'GB' maps to 'United Kingdom'.
Or do you want to store a simple collection of elements? Then use a Collection.
For example you could store types of tree, 'Oak', 'Pine' and 'Birch'.
Do you want to be able to access the key from the value as well as the value from the key? Then use a BidiMap.
For example you could convert country codes to text and text to country codes, allowing you to convert 'FR' to 'France' and 'France' to 'FR'.
Or do you just need a single direction lookup from key to value? Then use a Map.
For example you could convert a country code to text but not text to country code.
The BidiMap interface and implementations in Commons Collections allow you to lookup data in both directions. There are three implementations:
| DualHashBidiMap | Uses two HashMap objects internally. This implementation is a useful general purpose BidiMap that can store any object. The objects are stored in any order, and the order may change over time. |
| DualTreeBidiMap | Uses two TreeMap objects internally which means that keys and values must implement Comparable, unless a comparator is supplied. If considering this class, the TreeBidiMap is usually a better choice. However, this is the only implementation of the SortedBidiMap interface. |
| TreeBidiMap | Dedicated implementation that requires keys and values to implement Comparable, unless a comparator is supplied. This is an efficient implementation using a data structure that avoids duplicating data. The keys and values are held and viewed in sorted order, and the class implements the OrderedBidiMap interface. |
The Map interface and implementations in both the JDK and Commons Collections allow you to lookup data from a key to a value. This is one of the most powerful interfaces in the JDK, however it is very difficult to implement. These are the available implementations:
| HashMap (JDK) | This map is the most commonly used and fastest implementation. It is suitable for most situations and can store any object. Objects are stored in any order, and the order may change over time. |
| HashedMap | The Commons Collections hash map implementation which is very similar in design to HashMap, but also supports easy iteration via a MapIterator. This implementation is also designed to be subclassed. Use this map if you want to use the extra iterator, or to subclass. Otherwise, there is no advantage (or disadvantage) compared to the JDK HashMap. |
| IdentityMap | This map operates exactly as per HashedMap but compares keys and values using == not .equals(). |
| IdentityHashMap (JDK) | This map operates exactly as per HashMap but compares keys and values using == not .equals(). |
| TreeMap (JDK) | This map ensures that the keys are always sorted, and iteration order is consistent. All keys must implement Comparable, unless a comparator is supplied. This map should be used if you need the map to be sorted. |
| LinkedMap | This map maintains the order that each object is added to the map. When the map is viewed via an iterator, the insertion order will be seen. This map should be used if you need to retain the insertion order. |
| LinkedHashMap (JDK) | This map, available from JDK 1.4, maintains the order that each object is added to the map. When the map is viewed via an iterator, the insertion order will be seen. Commons collections' LinkedMap provides the same functionality for JDK1.2 onwards and provides a MapIterator. |
| ListOrderedMap | This map decorates another map to maintains the order that each object is added to the map. The order is maintained using a list. This map should be used if you need to retain the insertion order but you also need the special features of another map. |
| LRUMap | This map places a maximum size limit on the map and removes the least recently used (LRU) key-value when it is full. This map should be used for caches where you want to limit the maximum memory size used, and are happy with the least recently used algorithm for removals. |
| ReferenceMap | This map enables keys and values to be garbage collected whilst still held in the map. This can be useful for building memory sensitive caches. This map should be used for caches where you want to allow garbage collection from the map. |
| WeakHashMap (JDK) | This map stores each key-value pair with a key that can be garbage collected. This can be useful for building memory sensitive caches. ReferenceMap provides the same functionality but with much more flexibility. |
| ReferenceIdentityMap | This map operates exactly as per ReferenceMap but compares keys and values using == not .equals(). |
| SingletonMap | This map is restricted to storing one key-value pair. It may contain no more than and no less than one pair. It provides a MapIterator. This map should be used if you want to return one key-value pair and must use the Map interface. |
| Flat3Map | This map is optimised to store one, two or three key-value pairs and outperforms HashMap at these sizes. For size four and above performance is about 5% slower than HashMap. This map also has good garbage collection characteristics when below size four. It provides a MapIterator. This map should be used if are 99% sure that the map will be size four or less. |
| StaticBucketMap | This map is optimised to work well in a heavily loaded multi-threaded environment. It provides synchronization internally, locking on a per 'bucket' basis, where the buckets are fixed at construction time. You should use this class if you can predict the size of the map and you are working in a very intensive multi-threaded environment. |
Do you want to access each element by index? Then use a List.
Do you want to ensure that each element appears only once? Then use a Set.
Do you want to manage and keep count of multiple copies of the same element? Then use a Bag.
Do you want to be able to get or remove the next available object in the collection? Then use a Buffer.
Or do you want to just want an arbitrary collection of elements? Then use a Collection.