Bryce McKinlay wrote: > I also looked at your implementations of removeAll/retainAll in Vector > -- nice. But don't you think its odd that there would be optimized > implementations in Vector but not ArrayList? I wonder if we should put > those in ArrayList as well. In the past I have avoided including any > public methods that wern't part of the Javadoc spec, but that was more > to help ensure that the implementation worked similarly to Sun's rather > than for any real correctness reasons, since of course adding extra > virtual methods should not effect binary compatibility in any way in > Java. What do you think?
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 think Sun didn't notice the possibility for my optimization. I guess Vector has removeAll when ArrayList doesn't simply because Vector needs to be synchronized. Which is odd, because Sun didn't allow for iterator or listIterator in Vector, so I was unable to create iterators which were properly synchronized. Maybe we could use package-private hooks to work around these spec shortcomings while still maintaining the public API: AbstractList.java: public boolean removeAll(Collection c) { return internalRemoveAll(c); } boolean internalRemoveAll(Collection c) { // existing implementation } public Iterator iterator() { return internalIterator(); } Iterator internalIterator() { // existing implementation } ArrayList.java: boolean internalRemoveAll(Collection c) { // optimized implementation } Vector.java: Iterator internalIterator() { // synchronized implementation } It was a little easier working with the nested classes in Collections. For example, I added methods like Collections.EmptySet.toArray, which Sun did not implement (of course, I tested this using only java.lang.reflect, and not by decompiling or looking at JDK source). But in those nested classes, I did not feel guilty adding public methods because the entire class is private and undocumented except for its serializable nature. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath