commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Commons-Avalon:collections] code integration
Date Thu, 20 Jun 2002 17:55:06 GMT
> From: Jack, Paul [] 
> > I thought you did:
> > 
> > On Thu, 20 Jun 2002, Jack, Paul wrote:
> > > Iterator.remove() would have to completely recopy the 
> internal array 
> > > and reset the head and tail.  Again, it'd be extremely 
> slow -- but 
> > > wouldn't affect the add() and remove() implementations.
> Heh, poor word choice.  The elements would have to be shifted 
> but there wouldn't be any new memory allocations or 
> System.arraycopy involved.

A lot of shifting involved.

  What if the end index is before the begin index?  It is a
circular buffer, so that is within normal operating conditions.

Imagine this scenario:

       E     B

Remove (2).


Ok, I have to copy buf[0] to buf[6],
then I have to copy buf[1-2] to buf[0-1],
then I have to move the E marker.

The index operations are a place where error can creep in and
bite you in the butt.  It took a few bug fixes to get them to
operate correctly.

> > And I don't see why the *optional* operations *need* to be 
> supported.
> Well, the effort to support them is minimal; and it'd be a 
> bit wierd to have a collection that does support element removal but 
> raises UnsupportedOperation on the standard removal methods.

It seems normal to the Java spec writers.  Check the docs out
on Collections/Iterator.  It's not uncommon--Esp. with the

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message