On Apr 26, 2013, at 2:06 PM, David Holmes <[email protected]> wrote:
>>>>
>>>> To avoid blocking the feature, I have filed
>>>> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of
>>>> remove and other ListIterator methods after forEachRemaining returns.
>>>
>>> I think the fact that the last element can be removed should be specified
>>> as unspecified,
>>> because it's more an artefact of the default implementation than something
>>> which part
>>> of the semantics.
>>>
>>
>> I was wondering about that too. What happens if an implementing class
>> decides later on to override the default implementation? If the overriding
>> implementation does not conform to the same behaviour as the default it
>> could break compatibility.
>>
>> Plus one could change code from:
>>
>> while(it.hasNext() { doSomething(it.next()); }
>> doSomethingAtEnd(it);
>>
>> to
>>
>> it.forEachRemaining(this::doSomething}
>> doSomethingAtEnd(it);
>
> All implementations must obey the contract of the specification, and no
> clients should assume any kind of behaviour beyond what that contract says.
>
> That said I've lost the context of this particular issue - what is the
> problem here?
>
What is the state of the Iterator after a call to Iterator.forEachRemaining
e.g.:
void doSometingAtEnd(Iterator it) {
it.remove();
}
IMO overriding forEachRemaining implementations should place the iterator in
the same state as the default method implementation. We just need to call this
out more clearly in the docs.
Paul.
