Wouldn't it be nice to have an actual bag implementation to use with bag mappings? Why not support the Apache Commons bag implementation? Has anyone looked into this before?

Not sure what you mean by "have an actual bag implementation to use with bag mappings". There is one; its net.sf.hibernate.collection.Bag

Hibernate deals with interfaces (i.e., java.lang.List, java.lang.Set, java.lang.Map) when dealing with collections; not implementations.

As far as usage external to Hibernate and then have Hibernate know what to do with it that should be fine as long as it is exposed as the List interface. This would be essentially the same thing I do with ArrayLists now (the exposed get/set pair define List, but the actual property is initialized using "new ArrayList()")

Sorry, I'm not being all that clear today.

Apache commons defines a Bag interface in the collections hierarchy and has several concrete implementations of it. It's very similar to a Set, but it allows for multiple copies of the same item. You can use a hibernate bag mapping with a java List interface, but as the Hibernate documentation points out, the List semantics are not a very good match for hibernate's bag mapping, since Lists are indexed and bags are not.

My suggestion is that Hibernate have a java Bag implementation of the bag mapping, as well as the existing List implementation. Bags are EXTREMELY useful for instances where you have a many-to-many mapping where you allow for duplicate values. List implementations have no simple way of finding out how many instances of the same value are in the collection -- you basically have to iterate through the entire list.
Bags let you getCount(Object value) and usually have an efficient handling of large numbers of multiple objects.

I hope I'm being clear. I posted this suggestion on the JIRA earlier today and got immediately rejected because I believe someone got the impression that I meant to replace the use of the List interface with Bag, and thus make the apache commons-collections library a requirement for users (though Hibernate already requires it).

I would guess that it got rejected because you are suggesting that Hibernate impose a different type of requirement on users. Sure currently they need to have commons collections on the classpath, but your suggestion is that the would need to utilize commons collections specific classes for certain Hibernate functionalities.

The complaint is normally that Java does not provide a standard "bag" implementation. It does, however, provide a standard "bag" interface: java.util.Collection. As mentioned before, Hibernate deals with interfaces. The actually implementations are irrelevent, aside from normal casting rules.

I understand the purpose of a "bag", and a "bag" is in no way similiar to a Set. The java Set defines a discrete mathematical set (i.e., no duplicates). The concept of a set and a bag are completely opposite. Sure, there both unordered but the fundamental definition of a Set is opposed to that of bag usage.


And I'm saying you can acheive this in Hibernate already without touching a single line of Hibernate code. Simply expose the collection in your getters and setters as java.util.List (or even java.lang.Collection if you wish) and then map it as a bag.

I'm not actually suggesting anything that would impose on users. If they want their <bag> mappings to be a java List in their class, as they do now, they would leave their classes with a List. If they want it mapped to an apache Bag, they could use a Bag in their class.



I know that currently I can map a Hibernate bag to a Java List. I want to be able to map a hibernate bag to a Java/Apache Bag, because I find the semantics of the Apache bag interface useful, and a more suitable mapping than a List when you don't actually want a List. I could use the List interface in my class and then wrap it inside of a HashBag/TreeBag, but that would require a costly conversion, and would prevent the use of collection proxies.

Hmm... I think I see the communications problem here. For some reason, I was under the impression that Hibernate created collection instances of different classes depending on the results of reflection on the class, as looked up at mapping time. A closer look at the documentation shows that that's not so and, for example, a <set> mapping will always give you a net.sf.hibernate.collection.Set instance. I guess this should have seemed obvious, but for some reason I didn't see it, and I imagined a more complex implementation where it would be possible to customize which concrete class of the collection was created.

The problem with that is all the "stuff" the Hibernate collection impls do. Have a look at their source...