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

[Eric Blake]

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             address@hidden
  BYU student, free software programmer