[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: classpath ./ChangeLog java/util/AbstractList.ja...
Date: Mon, 22 Oct 2001 00:40:49 -0600

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

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
public boolean removeAll(Collection c)
  return internalRemoveAll(c);
boolean internalRemoveAll(Collection c)
  // existing implementation
public Iterator iterator()
  return internalIterator();
Iterator internalIterator()
  // existing implementation
boolean internalRemoveAll(Collection c)
  // optimized implementation
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]