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

[Bryce McKinlay]

Eric Blake wrote:

> 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:

There is no need to synchronize the Vector iterator. Its made pretty 
clear in the docs that iterators should never be shared among different 
threads (hence the ConcurrentModificationException), and of course any 
operations you actually perform on the iterator are still synchronized 
internally against the underlying Vector. Note also that there is no 
Collections.synchronizedIterator - it doesn't make sense because even if 
it were synchronized it still wouldn't be thread-safe.

> 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 

Actually I think these particular "optimizations" are very dubious!! 
;-). We should definatly try to optimize when the default behaviour can 
take quadratic time etc, but in this case I think the methods are not 
performance critical and don't justify the extra code. Your comment says 
that they "provide a performance advantage by not allocating unnecessary 
iterators in AbstractList", but I don't see why an iterator ever needs 
to be allocated. Why not just have a single, static empty iterator like 
before?

regards

Bryce.