map and null values
peter.levart at gmail.com
Thu Jan 3 08:37:11 PST 2013
On 01/03/2013 04:46 PM, Brian Goetz wrote:
> Another way of saying this is: this is easy for non-concurrent maps,
> but basically impossible for concurrent maps. Since these methods are
> being ported down from ConcurrentMap to Map, bending over backwards to
> accomodate uses that won't work anyway in their intended domain is a
> complete waste of energy.
The methods: remove(key, value), replace(key, oldValue, newValue),
replace(key, value) & putIfAbsent(key, value) are perfectly usable also
in non-concurrent and non-atomic domain, since they provide an
opportunity for optimization in various implementations. Currently there
is no way to achieve their semantics on plain Map (like j.u.HashMap)
without doing two lookups.
That's also true for computeIfAbsent and friends but the benefit is
questionable, since another lookup might be faster then the construction
of a lambda object.
> On 1/3/2013 10:40 AM, Doug Lea wrote:
>> On 01/03/13 09:57, Peter Levart wrote:
>>> And if there is a way to provide a single default
>>> implementation in j.u.Map that satisfies both ConcurrentMap
>>> implementations that
>>> don't allow nulls and plain Map implementations that allow nulls,
>>> why not
>>> provide it?
>> Feel free to try. The main constraint is that, to apply to
>> possibly-concurrent maps, the four new function-accepting
>> methods must be expressed only in terms of putIfAbsent,
>> replace, and/or two-argument remove. While I haven't tried
>> to prove this, I believe that all ways of doing it encounter
>> the null ambiguity.
More information about the lambda-dev