ConcurrentHashMap/ConcurrentMap/Map.compute

[Doug Lea]

On 12/05/12 08:40, Remi Forax wrote:
> You can distinguish between the fact that null is stored or not by using a
> dedicated functional interface that send if the value is present or not as
> parameter. For the return value, you can use a special value for saying NO_VALUE.
>

Right. This gets very low scores on usability/decodability.
But the big problem is that each concrete Map class itself
would need to supply something like this, because only it
knows if it accepts null values. Which precludes default
implementations. Well, you could default-implement this
as well, but in that case you might as well take the plain
default implementation in my version and let any class that wants
to do differently re-spec their override using some escape-hatch
wording. (The same sort of odd escape-hatch wording that is
used for example in IdentityHashMap telling readers to
disregard everything the Map specs say about method equals().)

-Doug



> interface MapFunction<K, V> { <-- better name needed
>    Object NO_VALUE = new Object();
>
>    // returns K| NO_VALUE
>    public Object apply(K key, boolean isPresent, String v);
> }
>
> As you see the way to specify the return type is ugly and unsafe.
>
> Now, given that people are used to Map.get() returning null, I think it's better
> to have apply returning a K with your proposed semantics.
>