org.apache.commons.collections.bidimap

This package contains implementations of the {@link org.apache.commons.collections.BidiMap BidiMap}, {@link org.apache.commons.collections.OrderedBidiMap OrderedBidiMap} and {@link org.apache.commons.collections.SortedBidiMap SortedBidiMap} interfaces. A BidiMap is an extension to Map that allows keys and values to be looked up with equal ease. One example usage is a system communicating to a legacy datasource that must convert codes from the new format to the old format and vice versa.

The following implementations are provided in the package:

• DualHashBidiMap - uses two HashMaps to implement BidiMap
• DualTreeBidiMap - uses two TreeMaps to implement SortedBidiMap
• TreeBidiMap - red-black tree implementation of OrderedBidiMap

The following decorators are provided in the package:

• Unmodifiable - ensures the map cannot be altered

Methods are forwarded directly to the decorated map.

This implementation does not perform any special processing with the map views. Instead it simply returns the set/collection from the wrapped map.

Methods are forwarded directly to the decorated map.

This implementation does not perform any special processing with the map views. Instead it simply returns the inverse from the wrapped map.

Methods are forwarded directly to the decorated map.

This implementation does not perform any special processing with the map views. Instead it simply returns the inverse from the wrapped map.

The setValue() method on iterators will succeed only if the new value being set is not already in the bidimap.

When considering whether to use this class, the TreeBidiMap class should also be considered.

This class guarantees that the map will be in both ascending key order and ascending value order, sorted according to the natural order for the key's and value's classes.

This Map is intended for applications that need to be able to look up a key-value pairing by either key or value, and need to do so with equal efficiency.

While that goal could be accomplished by taking a pair of TreeMaps and redirecting requests to the appropriate TreeMap (e.g., containsKey would be directed to the TreeMap that maps values to keys, containsValue would be directed to the TreeMap that maps keys to values), there are problems with that implementation. If the data contained in the TreeMaps is large, the cost of redundant storage becomes significant.