RFR: 8029055: Map.merge must refuse null values

[Brian Goetz]

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.