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

Chris Hegarty chris.hegarty at oracle.com
Tue May 19 16:19:07 UTC 2015

On 19 May 2015, at 17:13, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> On 19/05/15 12:07, Paul Sandoz wrote:
>>> 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.

+     * @implSpec
+     * The returned Iterator's {@link Iterator#hasNext hasNext} method calls and returns
+     * the value from this Enumeration's {@code hasMoreElements} method; its
+     * {@link Iterator#next next} method calls and returns the value from this Enumeration's
+     * {@code nextElement} method; and its {@link Iterator#remove remove} method throws
+     * {@code UnsupportedOperationException}.
+     *

Why not turn the proposed implSpec into an implNote, and leave it up to other API’s returning Enumerations to specify their behaviour of asIterator, if they override the default.


> Ah... Interesting use case. I hadn't thought of that.
> What should ConcurrentHashMap.keys().asIterator().remove() do?
> cheers,
> -- daniel

More information about the core-libs-dev mailing list