Null values

[snazy]

Current implementations of Int2ObjectHashMap, Long2ObjectHashMap + Object2ObjectHashMap do not allow null values.

This PR removes the requirement for values to be not-null. There are two commits in this PR:

• The first one adds nullable values by masking null values with NullReference.INSTANCE.
• The second one removes that masking and also fixes an issue in Object2ObjectHashMap that leaks object references to keys via Object2ObjectHashMap.AbstractIterator.remove(), as that method did only set the value to null but not the key.

As an alternative, there's another PR that adds the nullability of values in a slightly different way.

[mjpt777]

Thanks for pointing out the resource leak. I've fixed that now.

Null values are not allowed in maps as a drop in replacement for JDK collections so I'll close this PR. The other will nullable options I'll review as a more likely alternative.

[nitsanw]

"Null values are not allowed in maps as a drop in replacement for JDK collections"

The spec for Map is loose on that (which is a bad decision IMO):

Some map implementations have restrictions on the keys and values they may contain. For example, some implementations prohibit null keys and values, and some have restrictions on the types of their keys.

And:

If this map permits null values, then a return value of null does not necessarily indicate that the map contains no mapping for the key; it's also possible that the map explicitly maps the key to null. The containsKey operation may be used to distinguish these two cases.

It's a bit crap, as most people use the interface, but rely on some implementation. Commonly on HashMap which supports null keys and values.

[mjpt777]

@nitsanw you are right to point this out. I'm more conservative and like to rely on the intersection of what is available in HashMap and ConcurrentHashMap as what can be relied upon. It comes down to safety of expectations and respecting the principle of least surprise while keeping something remotely sane. Well at least keeping me remotely sane ;-)

If a Map is to support null keys for values then it is best to scream it out. This is why I favour the second of the PRs by @snazy which I will review. Happy to consider arguments for things I may have missed.

[nitsanw]

@mjpt777 I think you are arguing the right approach, which is "Map implementations must support K/V not null. They may also support nulls, but I can't rely on that.".
Agreed that verbose names are the way to go, as well as keeping the current implementations behavior the same.