Is it me or is it Hibernate?

It's very early in the relationship. But some things that ought to be very simple turn out to be hard. I had a bean property of type java.lang.URI, persisted in a table column as a varchar. How hard could it be to automate this mapping? Well, kinda. I had to create classes URIAccessor (implements PropertyAccessor), URIGetter (implements Getter), and URISetter (implements Setter). PropertyAccessor has two methods; Getter has four methods (two optional); Setter has three methods (two optional). So to persist a URI I had to create three Java classes and implement at least five methods. Mapping a URI class to a String column ought to be simple.

This is more troubling: I have a table having a composite primary key; the key columns are themselves foreign keys. This is the natural organization of the problem. The Hibernate documentation indicates Hibernate supports composite primary keys, but there are constraints on your Java class implementations... well, you can see what you have to do here: http://www.hibernate.org/hib_docs/reference/html/components.html.

If I have to go to that much trouble to contrive java classes that comport to my logical data model, I have to wonder why I am using such a tool in the first place. This O/R mapping tool is supposed to be *easier* than writing SQL!

The overriding principle I need in any O/R mapping is that the LDM ought to be inviolable. I don't mind writing any kind of hacky class methods to support that LDM. I want my data model to survive any program I write. Fifteen years from now programming languages will be more advanced, and I want my LDM independent of today's idioms.