[Top][All Lists]

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

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

From: Bryce McKinlay
Subject: Re: classpath ./ChangeLog java/util/AbstractList.ja...
Date: Tue, 23 Oct 2001 16:04:29 +1300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

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

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

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?



reply via email to

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