Is there a plan to override the default method asIterator() in specific
implementations of Enumeration to avoid creating new
object? JarFile::entries already returns JarEntryIterator which is both.
To be fair I did some tests and when I wrap Enumerable into simple Iterator
adapter it will almost always get scalar replaced by escape analysis
(unless, of course, it actually escapes :)).
On Tue, May 19, 2015 at 12:07 PM, Paul Sandoz <paul.san...@oracle.com>
wrote:
>
> On May 19, 2015, at 11:17 AM, Peter Levart <peter.lev...@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.
>
> Paul.
>
--
Tomasz Kowalczewski
