Skip to main content

Why no Bag (unordered collection w/duplicates)?

7 replies [Last post]
matthewadams
Offline
Joined: 2003-10-08

Why are there no direct implementations of java.util.Collection that allow duplicates and don't maintain order? Why is there no Bag interface (extends Collection) and has extra methods like "int getCountOf(Object)"?

Apache has some, and there are certainly others.

Why has the Java Collections framework not provided implementations or interfaces like this?

--matthew

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
wingetr
Offline
Joined: 2004-01-19

Better yet, use a Map! the key will be the object and the value is the count. Wrap this by a class that makes sure that no count is ever less than zero.

I developed a MoneyBag for one of my applications as a simple wrapper to such a Map (Currency as the key, Double as the value).

matthewadams
Offline
Joined: 2003-10-08

> Better yet, use a Map! the key will be the object
> and the value is the count. Wrap this by a class
> that makes sure that no count is ever less than
> zero.

Too much work. Repurposing and wrapping a Map is not convenient at all.

I just want a simple collection that allows duplicates and doesn't maintain order. Heck, I don't really even need the "int getCountOf(Object)" method. I just don't want to have to incur the performance penalty of order maintenance or uniqueness.

Why is this such a tall order?

--matthew

yishai
Offline
Joined: 2003-11-16

> Why are there no direct implementations of
> java.util.Collection that allow duplicates and don't
> maintain order? Why is there no Bag interface
> (extends Collection) and has extra methods like "int
> getCountOf(Object)"?
>
> Apache has some, and there are certainly others.
>
> Why has the Java Collections framework not provided
> implementations or interfaces like this?
>
> --matthew

Looking at the apache Bag interface, it has a couple of methods which violate the contract of Collection, which makes sense for a Bag interface, but you can't really expect the JDK to do that. So what would you expect a Bag interface to implement, besides int getCountOf(Object)?

If that is all, then I would vote to add it as a static method to the Collections class ( int getCountOf(Object, Collection) ) rather than starting a whole new interface.

matthewadams
Offline
Joined: 2003-10-08

> Looking at the apache Bag interface, it has a couple
> of methods which violate the contract of Collection,
> which makes sense for a Bag interface, but you can't
> really expect the JDK to do that

Why not?

> So what would you
> expect a Bag interface to implement, besides int
> getCountOf(Object)?
>
I just would like a Collection that doesn't do all of the extra work like iterating the collection checking for duplicates and maintaining order. Seems a reasonable enough request, and easy enough to implement as part of the standard Java Collections Framework.

> If that is all, then I would vote to add it as a
> static method to the Collections class ( int
> getCountOf(Object, Collection) ) rather than starting
> a whole new interface.

If that's all that's done, then I still incur the performance penalty of order maintenance or uniqueness within the collection.

I still want interface java.util.Bag added to the framework.

--matthew

yishai
Offline
Joined: 2003-11-16

> > Looking at the apache Bag interface, it has a
> couple
> > of methods which violate the contract of
> Collection,
> > which makes sense for a Bag interface, but you
> can't
> > really expect the JDK to do that
>
> Why not?

Then you would have Collection implementations in the JDK api which is not compatable with the Collections API in the JDK. If you find that worth it on a 3rd party project, great. But the JDK (or any project) can't be about contradicting itself.

> > So what would you
> > expect a Bag interface to implement, besides int
> > getCountOf(Object)?
> >
> I just would like a Collection that doesn't do all of
> the extra work like iterating the collection checking
> for duplicates and maintaining order. Seems a
> reasonable enough request, and easy enough to
> implement as part of the standard Java Collections
> Framework.

If all you do is add and iterate, what penalty is a list giving you in maintaining order? What implementation could you conceive of that doesn't implement order, and gains something by it?

When you first made the request, I thought you were asking about functionality and abstraction. (The Apache stuff is implemented with a Map (Hash or Tree) backing it, so there isn't a gain there). Now you are asking about performance. So my question is what algorithm will give you better performance and for what operations?

> I still want interface java.util.Bag added to the
> framework.

OK, but for what, just the name? An interface doesn't give you a better implementation, just a better abstraction.

tsinger
Offline
Joined: 2003-06-10

> Why has the Java Collections framework not provided
> implementations or interfaces like this?

Maybe because nobody needed it? And if you really need one, you can use a plain list for it and write the getObjectCount(Object) method yourself.

Tom

bjb
Offline
Joined: 2003-06-12

To have standard data structures available seem to me the job of the collection framework .... so maybe bag should be added.