JPA/Hibernate: What use is an ORM (Hibernate) when it doesn't get all JPA mappings right?

I've played a lot with Hibernate and JPA mapping in the last couple of months/weeks. My DB uses composite primary keys and I've reported approximately 10 to 15 Hibernate and 5-10 EclipseLink bugs. Hibernate is especially ridiculous in certain constellations that ought to be working. (I had the code checked by experts and JPA book authors)

The big question is:

What use is an ORM when it doesn't get all JPA mappings right?

Hibernate has soo much to offer, caching etcetc. I wonder who cares when developers can't even get past creating a working meta data model... It's all pointless. So again, what use is an ORM 开发者_JAVA百科when it doesn't get all JPA mappings right?

ORM is a tool. Ponder that sentence deeply.

It is usually believed that if a piece technology, Hibernate in this case, becomes popular enough in a specific domain, it is the silver bullet and that you have to use it, otherwise you're a loser.

This is plainly and utterly wrong. Hibernate is a tool that should be used appropriately.

Hibernate's authors say that Hibernate is best suited for new projects, where mappings are defined in xml or using annotations, and then Hibernate generates the DLL for your database and creates all tables and relationships.

The reverse can be very tricky, especially when you've got non normalized tables and composite primary keys.

That's why Hibernate strongly encourages use of primary surrogate keys that are autoincrementing.

Doing proper JPA reverse mapping is a challenge with many corner cases awaiting you in the wild, so you're doing the right thing by report all these bugs so they can be fixed. With some more persistence, I'm sure you'll be able to do your mappings perfectly and then everything after that should be much easier, since that first part is always the hardest.

With whatever problem I have with JPA, I create a testcase for all implementations and compare the behavior of the ORMs and the reactions of their communities. Hibernate is by far the worst - their JPA bugs are not even looked at. OpenJPA is somewhat behind EclipseLink feature wise but it looks stable. EclipseLink has bugs which still take some time, but there is activity and frequent upgrades. My questions in the mailing list were all answered in a professional way by Oracle people. It appears that currently EclipseLink is the winner. I am using composite primary keys without problems - without them I still would need secondary unique indexes. It is really useful being able to look up entities by a composite key so the surrogate key workaround seems to be an excuse to me. In EclipseLink one can even use an enum as primary key which is really useful for those numerous little lookup tables that control system behavor. See http://opensource.atlassian.com/projects/hibernate/browse/JPA-7