Re: classpath ./ChangeLog java/util/AbstractList.ja...

[Stuart Ballard]

Eric Blake wrote:
> 
> I dunno - I'm hesitant to add unspecified public methods to public
> classes, even though as you point out they will not destroy binary
> compatibility.

I've always been under the impression that it's absolutely fine to add
an overridden method for a method that's declared in a superclass; I
think of the fact that Sun does or doesn't do this in certain situations
as an implementation detail that's mistakenly published in the javadoc.
It's guaranteed to not break source or binary compatibility and it's
exactly what object orientation is all about.

Another Collections case that has a similar potential optimization is
LinkedList.subList(); the iterator() method on the sublist class would
normally be inherited from AbstractList, which calls
list.iterator(startIndex). On a linked list, iterator(n) is O(n). But if
the LinkedList sublist were to store the starting and ending Entry
objects, you can make this operation O(1).

Since creating an iterator is a pre-requisite for many many other
operations, I think making such an optimization for LinkedList sublists
is worth doing. Last I checked (which admittedly was at 1.2 release
time) Sun didn't do this. My old Classpath LinkedList implementation
did, but that was vaporized by the libgcj merge (and no great loss,
because in most other ways it sucked).

Stuart.