PATCH: More collections List updates

[Bryce McKinlay]

Stuart Ballard wrote:

> My implementation included
> an override of LinkedList.subList() to store a pointer to the Entry
> objects of the first-1 and last+1 nodes. Thus listIterator(i) on the
> subList is only O(i).

I'm not sure I agree with you about overriding subList() in LinkedList. Sure,
it would make the listIterator() call faster on a LinkedList-backed SubList,
but is it worth all the extra complexity and code duplication that is
necessary to do it? Note that your existing implementation of this was not
correct, because it did not add concurrent modification checks in all the
necessary places.

It seems like might be reasonable, however, to extend AbstractList.SubList
from LinkedList and only override its listIterator() method?  Unfortunatly I
seem to recall thinking there was some reason why this wouldn't work. But I
will look into it...

> FWIW, I noticed recently that you changed AbstractList.iterator() to
> simply return this.listIterator(). I agree with this change, but it's
> worth mentioning that (at least as of the late betas of JDK1.2) Sun did
> not agree with it, because I sent that very question to Sun before I
> made the original implementation.

Right. I don't really see a problem with it either, especially since all the
various other list implementations (SubList, LinkedList, etc) do exactly
that. Worth thinking about though, if we want to get every little detail
compatible with Sun's implementation. The original implementation returned
anonymous classes for the iterators and duplicated code between them, which I
didn't like, but now that I think about it we should be able to simply have
the ListIterator implementation extend the Iterator implementation, without
much extra code.

regards

  [ bryce ]