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, particularly when trying to keep the two TreeMaps synchronized with each other. And if the data contained in the TreeMaps is large, the cost of redundant storage becomes significant. (See also the new {@link org.apache.commons.collections.bidimap.DualTreeBidiMap DualTreeBidiMap} and{@link org.apache.commons.collections.bidimap.DualHashBidiMap DualHashBidiMap}implementations.)
This solution keeps the data properly synchronized and minimizes the data storage. The red-black algorithm is based on TreeMap's, but has been modified to simultaneously map a tree node by key and by value. This doubles the cost of put operations (but so does using two TreeMaps), and nearly doubles the cost of remove operations (there is a savings in that the lookup of the node to be removed only has to be performed once). And since only one node contains the key and value, storage is significantly less than that required by two TreeMaps.
There are some limitations placed on data kept in this Map. The biggest one is this:
When performing a put operation, neither the key nor the value may already exist in the Map. In the java.util Map implementations (HashMap, TreeMap), you can perform a put with an already mapped key, and neither cares about duplicate values at all ... but this implementation's put method with throw an IllegalArgumentException if either the key or the value is already in the Map.
Obviously, that same restriction (and consequence of failing to heed that restriction) applies to the putAll method.
The Map.Entry instances returned by the appropriate methods will not allow setValue() and will throw an UnsupportedOperationException on attempts to call that method.
New methods are added to take advantage of the fact that values are kept sorted independently of their keys:
Object getKeyForValue(Object value) is the opposite of get; it takes a value and returns its key, if any.
Object removeValue(Object value) finds and removes the specified value and returns the now un-used key.
Set entrySetByValue() returns the Map.Entry's in a Set whose iterator will iterate over the Map.Entry's in ascending order by their corresponding values.
Set keySetByValue() returns the keys in a Set whose iterator will iterate over the keys in ascending order by their corresponding values.
Collection valuesByValue() returns the values in a Collection whose iterator will iterate over the values in ascending order. @deprecated Replaced by TreeBidiMap in bidimap subpackage. Due to be removed in v4.0. @see BidiMap @see org.apache.commons.collections.bidimap.DualTreeBidiMap @see org.apache.commons.collections.bidimap.DualHashBidiMap @since Commons Collections 2.0 @version $Revision: 1.14 $ $Date: 2004/02/18 01:15:42 $ @author Marc Johnson
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |