a patch for new default methods in Map + more
Peter Levart
peter.levart at gmail.com
Fri Jan 4 09:11:34 PST 2013
Hi,
I propose a patch for some new default methods in j.u.Map and some more:
http://dl.dropbox.com/u/101777488/jdk8-lambda/Map/webrev.02/index.html
The patch consists of 3 parts. Each can be taken individually or
together (or not at all).
*1st part* is a patch to methods Map.compute and Map.merge.
The Map.compute changes fix a NPE or infinite loop when executing the
following code:
Map<Integer, String> map = new HashMap<>();
map.compute(1, (k, v) -> "x");
...loops infinitely and:
Map<Integer, String> map = new ConcurrentHashMap<>();
map.compute(1, (k, v) -> "x");
...throws NPE.
In conversation with Doug we came to conclusion that this is the best we
can do (so far). The semantics of compute is now such that if there is
already a mapping in the Map {key->null} and a compute is called for the
key, the mapping will not be touched although the method will return the
value produced by the function. This behaviour is consistent with
computeIfAbsent and merge.
The Map.merge changes are just optimization (the returned value from the
putIfAbsent is used in new iteration of loop saving another get).
Otherwise the semantics stays the same.
*2nd part* is a little javadoc change in ConcurrentMap.remove(k, v) and
ConcurrentMap.replace(k, oldV, newV) as well as those two methods in
j.u.Map. The corresponding default methods in j.u.Map are changed
accordingly. This change eliminates a NPE when there is already a
mapping present in Map {key->null} and those methods are called with the
key.
*3rd part* is just a preview. All 8 new default methods of j.u.Map are
re-implemented in j.u.HashMap so that they are more optimal. The
semantics (also the behaviour with null keys/values as arguments and as
entries already in the map) should be exactly the same as that of
default methods in j.u.Map. Javadocs and tests are missing, but I'm
going to add them if this is something that might be considered to be
included.
Regards, Peter
More information about the lambda-dev
mailing list