Why not just switch them?
If you require two-way hash-based lookup, then create your own object that aggregates two HashMaps (not Hashtable, by the way--don't use that class over a HashMap unless you have a really good reason).
Instead of this approach, you could also have this class implement the Map interface and simply pass all the Map methods thru to your internal map instance (and populate the reverseMap when necessary). Then just add that one extra getByValue() method to use the reverseMap.
Or, instead of adding that one extra method directly to your TwoWayHashMap API, you could add a method instead that returns an instance of the Map interface backed by the reverseMap. That way you could get all of the Map functionality of the map when looking up forwards or backwards.
If you take this last approach, I highly recommend you return an unmodifiable view of the reverseMap. This forces the caller to modify your TwoWayHashMap through the main API only, not through an obtained reverseMap.
Using this method, it's important to note that this TwoWayHashMap is not thread-safe. That is, if one
thread is putting in the main map, and another thread is reading from the view of the reverseMap, it's possible to get weird and inconsistent results. Initializing your internal maps to be synchronized won't help either because you need to sync operations *between* the two internal maps.
Fortunately, the good people at Sun already thought of this. All you have to do is have clients of this object instantiate sync'd TwoWayHashMaps wherever they are needed, using the standard mechanism: