Seeking a smarter idiom

     Here's something I find myself doing a lot:

    Map<KeyType,MutableType> map = ...;
    ...
    KeyType key = ...;
    MutableType value = map.get(key);
    if (value == null) {
        value = new MutableType();
        map.put(key, value);
    }
    value.update(...info...);

(If I were in the habit of storing null values in Maps, I'd
also need a containsKey() test.) The last time I did this
the keys were host names and each value held a summary of the
traffic to and from its host: when a previously unknown host
entered the picture, a new record got created for it and
added to the Map.

     Fine and dandy, but something always irks me about this
idiom. Take my photo and color it old-fashioned, but I can't
help noticing that the map.put() operation almost certainly
duplicates most of the work of the unsuccessful map.get() that
preceded it. I'm working twice as hard as I "should" to insert
a new key/value pair, because map.put() cannot exploit the
information gained by map.get(). (At least, I don't think it
can: I haven't looked at the sources of HashMap and TreeMap,
but I find it hard to imagine how they could avoid two searches.)

     Given a suitable MutableType, the second search could be
avoided by making use of the value returned by map.put():

    Map<KeyType,MutableType> map = ...;
    ...
    KeyType key = ...;
    ValueType value = new Value(...info...);
    ValueType oldValue = map.put(key, value);
    if (oldValue != null)
        value.assimilate(oldValue);

This makes me itchy, too (perhaps unnecessarily). The "obvious"
scheme is to create a blank record the first time a key appears
and then keep updating it as additional information arrives; the
approach above creates a new record every time a new driblet of
data comes in, throwing away the old one after incorporating its
goodies into the new. Gives me goose pimples, it does.

     What idioms and patterns do other folks use for this sort of
thing? It seems a pretty common task to want to accomplish;
surely someone's got a better idea ...?

--
Eric Sosman
esosman@acm-dot-org.invalid