I just realized that in a 1-* relationship, hibernate does not offer many options other than what is exposed in section 22.2 of doc 3.0.3. those options would be :
- a unidirectional 1-* (cf section 8.2.3 - really not recommended)
- composite elements (cf section 22.5 - unfortunately, there are 2 big limitations to composite element classes ...)

so in the end, working with 1-* in hibernate means :
- one-to-many in the parent with inverse=true
- many-to-one in child
- a collection in the parent class, and a backpointer in the child class

the application is then in charge of maintaining the cohesion between the collection and the backpointer, which means :
- either not forgetting to do both a) manipulating collection and b) setting backpointer accordingly in child (cf section 23.3). this can be tricky considering that is something the developer as to remember for every write action that involves the collection : add, remove, set, retain, iterate and remove or set
- or implement some helper methods on the owning class to do the work for you (cf section 22.2): p.addChild(c). but then you would limit what you can with the list; plus you would want a special iterator to be returned when calling Parent.iteratorChild() so that you can intercept the set and remove actions on the iterator.

I would really want Hibernate to recognize that when I have a 1-*, and assuming that in my application I do not have a need to navigate from the child to the parent, a collection in the parent should be enough.

this sounds like an odd constraint to require the object model to provide bidirectionality and ask the application to ensure cohesion, specially when the application has no need for bidirectionality (ie: I just want my parents to hold a collection of my children) and considering that 1-* probably count for 50% of all relationships.

am I just too idealistic, or is there a technical challenge behind this constraint?