RFR: 8005051: optimized defaults for Iterator.forEachRemaining

Remi Forax forax at univ-mlv.fr
Wed Apr 24 17:57:24 UTC 2013


On 04/24/2013 07:24 PM, Akhil Arora wrote:
> On 04/24/2013 06:19 AM, Alan Bateman wrote:
>> On 23/04/2013 20:18, Akhil Arora wrote:
>>> On 04/22/2013 11:42 AM, Alan Bateman wrote:
>>>> One thing I meant to ask when forEachRemaining was added was 
>>>> whether it
>>>> should say anything about the "last element"? I see in the webrev that
>>>> you've set it for the ArrayList iterators but not the LinkedList
>>>> iterator - should it?
>>>
>>> done, and added more tests for the state of the iterator after
>>> forEachRemaining returns
>>>
>>> http://cr.openjdk.java.net/~akhil/8005051.2/webrev/
>>>
>>> (a portion of version 1 of the webrev has already been pushed to TL as
>>> part of rev 6973 
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76)
>> The remaining changes in the webrev looks okay to me. Also good to have
>> the test expanded.
>>
>> So do you think that the javadoc should say anything about the
>> relationship between forEachRemaining and remove?
>
> Good question. forEachRemaining docs state -
>
> Implementation Requirements:
>
>     The default implementation behaves as if:
>
>     while (hasNext())
>              action.accept(next());
>
> so a subsequent remove() should remove the last element.
>
> 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.

Rémi







More information about the core-libs-dev mailing list