Possible HashMap update

[Remi Forax]

On 08/14/2013 01:16 PM, Doug Lea wrote:
> On 08/13/13 16:56, Remi Forax wrote:
>>>>>
>>>>> And that the iterators on entrySet, keySet and values doesn't have 
>>>>> their method
>>>>> forEachRemaining overriden
>>>>> (unlike java.util.ArrayList).
>>>
>>> Are you saying that all iterators should define forEachRemaining?
>>> Seems excessive.
>>
>> All iterators for ArrayList, HashMap and their views should have 
>> forEachRemaining,
>> I don't care about the other collections :)
>>
>> forEachRemaining internally use local variables instead of fields as the
>> traditional iterator does,
>> so it may be faster than a plain old iterator loop. Moreover, the 
>> call to the
>> Consumer inside
>> the default method defined in Iterable can be megamorphic,
>> if each iterator's view have they own implementation, you create a 
>> several of
>> different callsites
>> (I know, I know, it's a kind of poor's man optimization) that 
>> mitigates the
>> profile pollution problem.
>>
>
> Could you explain exactly when these trigger? Most Stream-related
> operations should pick up spliterator, not iterator, so won't
> encounter this.

Yes, it's not related to Stream.
I see two obvious scenarios when forEachRemaining should be used.

The first one is bug 6360734 [1], for(:) doesn't support Iterator but 
there are
plenty of methods in the wild that returns an Iterator.
In the JDK, at least
   BeanContextServices.getCurrentServiceClasses(),
   BenContextSupport.bcsChildren() or
   ServiceRegistry.getCategories(),
all return something like map.[views()].iterator()

The second scenario is when you have an algorithm that do something for 
first value
and do something else for the other value, in that case, you need to get 
the iterator,
calls next to get the first value and calls forEachRemaining for 
processing the
remaining values.

>
> I resist this a bit because it would require 6 more
> methods, each redundant with a spliterator method.
> (The HashMap view ones must be overridden in LinkedHashMap.)
> But if the situation is common, it might be worthwhile.

I suppose that it depends on what is your definition of common :)

>
> -Doug
>
>
>
>

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6360734