RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
Remi Forax
forax at univ-mlv.fr
Thu Jun 13 21:48:40 UTC 2013
On 06/13/2013 05:42 PM, Mike Duigou wrote:
> On Jun 13 2013, at 00:56 , Paul Sandoz wrote:
>
>> On Jun 13, 2013, at 8:42 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>> On 06/13/2013 01:14 AM, Mike Duigou wrote:
>>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>>>
>>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>>> Hello all;
>>>>>>
>>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>>>
>>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>>>
>>>>>> Mike
>>>>> Hi Mike,
>>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.
>>> The javadoc for Map.forEach says differently:
>>>
>>> default void forEach(BiConsumer <http://download.java.net/jdk8/docs/api/java/util/function/BiConsumer.html><? superK <http://download.java.net/jdk8/docs/api/java/util/Map.html>,? superV <http://download.java.net/jdk8/docs/api/java/util/Map.html>> action)
>>>
>>> Performs the given action on each entry in this map, in the order entries are returned by an entry set iterator (which may be unspecified)
> Would anyone object to removing the ", in the order entries are returned by an entry set iterator (which may be unspecified)" clause? It seems like unnecessary over-specification.
>
> Mike
No :)
I think it's an important property because with that property people can
refactor from a for(:map.entrySet()) to a map.forEach() and vice-versa.
Rémi
>
>
>> Right, LinkedHashMap should preserve the encounter order on traversal, bulk or otherwise.
>>
>> Note that there is a bug logged against LinkedHashMap.spliterator. It should but currently does not report ORDERED for key/value/entry Spliterators.
>>
>> Paul.
More information about the core-libs-dev
mailing list