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. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath