On May 19, 2015, at 6:19 PM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>
> On 19 May 2015, at 17:13, Daniel Fuchs <daniel.fu...@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 ...".
Paul.
