Coming late to the party...
Overall I'll +1 this change, with the following nit:
@throws NullPointerException if the specified key or value is null and
* this map does not support null keys or values, or the
* remappingFunction is null
This should be:
@throws NullPointerException if the specified key is null and
* this map does not support null keys, or if the
* value or remappingFunction is null
See the new thread for the general Javadoc issues. I'll focus on null here.
There is really no choice over the names, or the broad-brush semantics.
These methods came from ConcurrentMap; default methods let us pull
these methods down to all maps (minus atomicity) and have them gain
atomicity in the context of a ConcurrentMap.
The overall "the docs could be better" arguments are well-taken but
we're deep in "the perfect is the enemy of the good" territory. The
choices at this point are: fix the merge(null) problem, or do nothing;
doing nothing seems far worse.
Yes, I get that nulls in collections are a pain, but trying to
redefine the meaning of "absent" is more of a pain. I'm aware that
ConcurrentMap makes things interesting, but these two just look wrong.
> So, my rules would be
OK, but the alternatives look just as wrong from other perspectives, and
we have an existing 10-year-old set of semantics with which to remain
compatible. There's no free lunch here. This is an uneasy compromise,
no matter how you slice it. We can either bring the semantics of these
ConcurrentMap methods down to Map, or we can not bring them to Map at
all. With these semantics, they're imperfect, but still darn useful.
