You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2006/02/10 01:28:17 UTC
[collections] Collections 3.2/4.0
Plan for collections 3.2
------------------------
Agree contents
(notably, I'd like to remove BoundedBuffer)
Check bugs
Build and release in single jar format
Plan for collections 4.0
------------------------
Break collections into smaller jars
(either as one project or multiple)
Remove deprecations (maybe to a deprecated jar)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Your logic is fine if you ignore performance. Unfortunately, collections
are often an area where performance is key.
A BoundedBuffer wrapping a FifoBuffer suffers from two performance
degredations:
- any decorator adds about a 5% overhead IIRC
- The FifoBuffer is less efficient than a plain BoundedFifoBuffer as it
must check for size changes directly on each add
Its not that BoundedBuffer is badly written, or that it isn't
theoretically how a modular OO system can be designed, its just that its
inappropriate in this case. Bounded-ness just happens to be best treated
as a fundamental property of the implementation.
Stephen
James Carman wrote:
> I don't know that I agree that the other implementations are more "correct"
> necessarily. The bounding logic can (and has been) abstracted out as a
> wrapper class. So, ideally you could bound any buffer using BoundedBuffer.
> So, if you wanted to use a FifoBuffer (queue) or a LifoBuffer (stack), you
> could bound it by wrapping it with a BoundedBuffer. Maybe it would be
> better called a BoundedBufferDecorator or something. Isn't this how
> object-oriented systems are supposed to be designed, modular?
>
>
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Friday, February 10, 2006 7:47 AM
> To: Jakarta Commons Developers List
> Subject: Re: [collections] Collections 3.2/4.0
>
> BoundedBuffer is unreleased, so can be removed.
>
> I want to remove it, as I believe it doesn't hold its
> weight. If you want a bounded buffer, our
> recommendation is to use BoundedFifoBuffer or
> CircularFifoBuffer. These are both optimised
> implementations for the fixed size.
>
> Adding BoundedBuffer only serves to draw attention
> away from the 'correct' implementations that people
> should be using.
>
> Stephen
>
>
> --- Henri Yandell <fl...@gmail.com> wrote:
>
>>On 2/9/06, James Carman <ja...@carmanconsulting.com>
>>wrote:
>>
>>>What would make BoundedBuffer more a 4.0 thing as
>>
>>opposed to a 3.2 thing?
>>
>>>Or were you saying that we should agree on the
>>
>>contents for 4.0?
>>
>>Removing things from an API happened at major
>>version numbers rather
>>than minor ones I thought.
>>
>>Hen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] Collections 3.2/4.0
Posted by James Carman <ja...@carmanconsulting.com>.
I don't know that I agree that the other implementations are more "correct"
necessarily. The bounding logic can (and has been) abstracted out as a
wrapper class. So, ideally you could bound any buffer using BoundedBuffer.
So, if you wanted to use a FifoBuffer (queue) or a LifoBuffer (stack), you
could bound it by wrapping it with a BoundedBuffer. Maybe it would be
better called a BoundedBufferDecorator or something. Isn't this how
object-oriented systems are supposed to be designed, modular?
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Friday, February 10, 2006 7:47 AM
To: Jakarta Commons Developers List
Subject: Re: [collections] Collections 3.2/4.0
BoundedBuffer is unreleased, so can be removed.
I want to remove it, as I believe it doesn't hold its
weight. If you want a bounded buffer, our
recommendation is to use BoundedFifoBuffer or
CircularFifoBuffer. These are both optimised
implementations for the fixed size.
Adding BoundedBuffer only serves to draw attention
away from the 'correct' implementations that people
should be using.
Stephen
--- Henri Yandell <fl...@gmail.com> wrote:
> On 2/9/06, James Carman <ja...@carmanconsulting.com>
> wrote:
> > What would make BoundedBuffer more a 4.0 thing as
> opposed to a 3.2 thing?
> > Or were you saying that we should agree on the
> contents for 4.0?
>
> Removing things from an API happened at major
> version numbers rather
> than minor ones I thought.
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
BoundedBuffer is unreleased, so can be removed.
I want to remove it, as I believe it doesn't hold its
weight. If you want a bounded buffer, our
recommendation is to use BoundedFifoBuffer or
CircularFifoBuffer. These are both optimised
implementations for the fixed size.
Adding BoundedBuffer only serves to draw attention
away from the 'correct' implementations that people
should be using.
Stephen
--- Henri Yandell <fl...@gmail.com> wrote:
> On 2/9/06, James Carman <ja...@carmanconsulting.com>
> wrote:
> > What would make BoundedBuffer more a 4.0 thing as
> opposed to a 3.2 thing?
> > Or were you saying that we should agree on the
> contents for 4.0?
>
> Removing things from an API happened at major
> version numbers rather
> than minor ones I thought.
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by Henri Yandell <fl...@gmail.com>.
On 2/9/06, James Carman <ja...@carmanconsulting.com> wrote:
> What would make BoundedBuffer more a 4.0 thing as opposed to a 3.2 thing?
> Or were you saying that we should agree on the contents for 4.0?
Removing things from an API happened at major version numbers rather
than minor ones I thought.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] Collections 3.2/4.0
Posted by James Carman <ja...@carmanconsulting.com>.
What would make BoundedBuffer more a 4.0 thing as opposed to a 3.2 thing?
Or were you saying that we should agree on the contents for 4.0?
-----Original Message-----
From: Henri Yandell [mailto:flamefew@gmail.com]
Sent: Thursday, February 09, 2006 8:26 PM
To: Jakarta Commons Developers List
Subject: Re: [collections] Collections 3.2/4.0
On 2/9/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Plan for collections 3.2
> ------------------------
> Agree contents
> (notably, I'd like to remove BoundedBuffer)
Shuoldn't that be a 4.0 thing?
> Check bugs
>
> Build and release in single jar format
>
>
> Plan for collections 4.0
> ------------------------
> Break collections into smaller jars
> (either as one project or multiple)
We getting lots of complaints of it being too large? Or just some noisy
ones?
Bear in mind, if we have a bunch of jars that people will only
complain that it's confusing and there are too many jars.
> Remove deprecations (maybe to a deprecated jar)
Just kill them I reckon; there's only so much effort we should go to
maintain legacy things, otherwise it all gets very painful.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by Henri Yandell <fl...@gmail.com>.
On 2/9/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Plan for collections 3.2
> ------------------------
> Agree contents
> (notably, I'd like to remove BoundedBuffer)
Shuoldn't that be a 4.0 thing?
> Check bugs
>
> Build and release in single jar format
>
>
> Plan for collections 4.0
> ------------------------
> Break collections into smaller jars
> (either as one project or multiple)
We getting lots of complaints of it being too large? Or just some noisy ones?
Bear in mind, if we have a bunch of jars that people will only
complain that it's confusing and there are too many jars.
> Remove deprecations (maybe to a deprecated jar)
Just kill them I reckon; there's only so much effort we should go to
maintain legacy things, otherwise it all gets very painful.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Stephen Colebourne wrote:
> Plan for collections 3.2
> ------------------------
> Agree contents
> (notably, I'd like to remove BoundedBuffer)
Task complete. We'll include BoundedBuffer. I'd just like a little more
javadoc, James?
> Check bugs
Bugzilla shows no outstanding bugs that we can fix.
> Build and release in single jar format
Any objections to this? Its well overdue.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2006-02-20 at 18:26 +0000, Stephen Smith wrote:
> Hi,
>
> I might be joining this party a little late, but what value do Commons
> Collections developers feel there might be in splitting Commons
> Collections into multiple JARs?
here's how i see things...
commons collections is really a suite of related libraries. concern
about the overall size of the distribution has meant that individual
areas (for example, collection-functors) have not been allowed to
develop to their full potential.
there's now enough critical mass to start factoring a very big
distribution into a suite of small but related bricks.
> I'm all in favour of removing deprecated code, but when I think of JAR
> splitting I think of what happened with Ant 1.6.x - I know plenty of
> developers that now refuse to upgrade Ant. I'd be interested to hear
> arguments in favour of splitting up Commons Collections. :)
i must have missed that particular controversy. could you elaborate?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by Stephen Smith <st...@stephen-smith.co.uk>.
Hi,
I might be joining this party a little late, but what value do Commons
Collections developers feel there might be in splitting Commons
Collections into multiple JARs?
I'm all in favour of removing deprecated code, but when I think of JAR
splitting I think of what happened with Ant 1.6.x - I know plenty of
developers that now refuse to upgrade Ant. I'd be interested to hear
arguments in favour of splitting up Commons Collections. :)
Steve.
--
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/
Michael Heuer wrote:
> Stephen Colebourne wrote:
>
>> Plan for collections 3.2
>> ------------------------
>> Agree contents
>> (notably, I'd like to remove BoundedBuffer)
>>
>> Check bugs
>>
>> Build and release in single jar format
>>
>>
>> Plan for collections 4.0
>> ------------------------
>> Break collections into smaller jars
>> (either as one project or multiple)
>>
>> Remove deprecations (maybe to a deprecated jar)
>
> Looking ahead a bit further, at what point might the following issues
> being addressed, if at all?
>
> - bringing external jdk1.5/generics project(s) back to commons
>
> - deprecating [collections] functor in favor of [functor] project
>
> - resolving Collection contract violations in Bag interface
>
> - AbstractHashedMap design improvements (Bugzilla Bug 27231)
>
> michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Collections 3.2/4.0
Posted by Michael Heuer <he...@acm.org>.
Stephen Colebourne wrote:
> Plan for collections 3.2
> ------------------------
> Agree contents
> (notably, I'd like to remove BoundedBuffer)
>
> Check bugs
>
> Build and release in single jar format
>
>
> Plan for collections 4.0
> ------------------------
> Break collections into smaller jars
> (either as one project or multiple)
>
> Remove deprecations (maybe to a deprecated jar)
Looking ahead a bit further, at what point might the following issues
being addressed, if at all?
- bringing external jdk1.5/generics project(s) back to commons
- deprecating [collections] functor in favor of [functor] project
- resolving Collection contract violations in Bag interface
- AbstractHashedMap design improvements (Bugzilla Bug 27231)
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] Collections 3.2/4.0
Posted by James Carman <ja...@carmanconsulting.com>.
Stephen,
What's wrong with BoundedBuffer?
James
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Thursday, February 09, 2006 7:28 PM
To: Jakarta Commons Developers List
Subject: [collections] Collections 3.2/4.0
Plan for collections 3.2
------------------------
Agree contents
(notably, I'd like to remove BoundedBuffer)
Check bugs
Build and release in single jar format
Plan for collections 4.0
------------------------
Break collections into smaller jars
(either as one project or multiple)
Remove deprecations (maybe to a deprecated jar)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org