Possible HashMap update

[Remi Forax]

On 08/15/2013 04:33 PM, Doug Lea wrote:
> On 08/14/13 09:23, Remi Forax wrote:
>> 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).
>>>>>
>>> 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 :)
>>
>
> Neither of these cases apply to existing usages, so I'm thinking
> that they are not common enough to support. Does anyone else
> think otherwise?

What, ?, it seems we don't live in the same world.
Google the query: apache .java "public Iterator" -Iterable
and you will get hundred of methods that returns an iterator with the 
top level class non Iterable,
currently calling forEachRemainig on these iterators will be optimized 
if the iterator was produced
by an ArrayList but not if it was created from one of the views of HashMap ?

Or do you suggest that we should not provide a better implementations 
for this particular default method,
which in that case indicates that this default method should be removed ?

>
> -Doug
>

Rémi