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

[Chris Hegarty]

On 20/05/15 08:20, Paul Sandoz wrote:
>
> On May 19, 2015, at 6:19 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>>
>> 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.
>>
>
> The @implSpec section is specifying the behaviour of the default implementation. Usually we prefix with "The default implementation ...".

D'oh, I mixed up @implSpec and @implNote (again). What Stuart has 
already cover this.

-Chris.

> Paul.
>