RFR(s): 8072726: add adapter to convert Enumeration to Iterator

Paul Sandoz paul.sandoz at oracle.com
Tue May 19 10:07:39 UTC 2015

On May 19, 2015, at 11:17 AM, Peter Levart <peter.levart at gmail.com> wrote:

> Hi,
> On 05/18/2015 12:20 PM, Paul Sandoz wrote:
>> Hi Stuart,
>> I would like to suggest some tweaks to the specification to get across this method is transitioning control of traversal from enumeration to iterator. How about:
>>   Returns an iterator that traverses the remaining elements covered by this enumeration.
>>   Traversal is undefined if this enumeration is operated on after the call to {@code asIterator}.
> I suppose this part of specification allows alternative overridden implementations of asIterator() method that return Iterator implementation that is more optimal in sense of not delegating to the Enumeration, but using it's own state, right?

Yes, i did have that in mind, but mostly it was proposed that way to get across the sense of transferring control of traversal for the remaining, untraversed, elements.

> Should anything be said also about default remove() method inherited from Iterator interface? Are custom asIterator() implementations allowed to return an Iterator that implements remove() in a way that actually removes elements?

Since this method transfers control it seems a little mean to place such a restriction on the returned Iterator. Although, there is no clear means of stating to the caller whether such an iterator supports removal or not, but that seems to be generally the case for any Iterator returning method.


More information about the core-libs-dev mailing list