I started to learn Hibernate, but switched to JDO in learning.

Now I feel that JDO is not very well designed: JDO doesn't seem easy to use and it lacks important features.

Is there a list of the pros and cons of Hibernate vs. JDO? Or can you tell me the pros and cons?

Why would Hibernate be used instead of JDO or vice versa?

JDO is typical commitee work... with some horribly bad tradeoffs. Don't touch it.

I started learning JDO six months ago.

I did it mainly because it was the standard (JCP and stuff), but when I tried to get it to work (with Open Source and commercial demo's) I realized two things:

1. JDO tries to entirely abstract persistence mechanisms, so it tries to be too generic!! To the point where doing anything slightly complex (like in most real world apps) it has to be extended using propietary extensions. So much for standards.

2. You wannt JDO to abstract persistence mechanisms? I've only heard of one implementation that can do this. Most of the JDO implementations out right now only support RDBMS

The two main reasons I changed to hibernate (after searching the web)

1. Open Source

2. Documentation (and most important) support readily available

3. It concentrates on one thing: ORM. (and does a fine job).

Hibernate is not an official standard: but the community it has backing it up is as good as any standard in my opinion.[/list]

Its unbelievable!

I spent a whole day trying to work with JDO without any success!!!

I tried a few tutorials and a few JDO implementations. None worked. Of course it works somehow, but I don't know how.

When I tried Hibernate with the Eclipse plugin, everything worked from the start.

Now I really start to hate JDO. I wrote a email to IntelliBO because their license does not work for the Eclipse plugin. Lets see if they can help me.

Nevertheless I need to know JDO better to exactly tell why I think it is shit. Until now it looks like it, although it seems better than Entity Beans.

Why must easy things be complicated?

Well, as usual we don't much like commenting upon the competition. We'd much rather that let our software speak for itself. Nevertheless, we recognize that people are trying to sell Hibernate to management and we suppose its our responsibility to help make that easier. So lets step into territory that is naturally controversial. We'll answer the question directly for once: why should you use Hibernate rather than any of the existing commercial JDO products. (We won't address opensource competition like OJB, TJDO, etc, because we don't diss other opensource efforts. Ever.) We could argue for hours about minor technical advantages and disadvantages but for now lets focus on the big differences:

Hibernate is a functional superset of JDO

The Hibernate APIs and query language solve problems that are not addressed by the JDO spec. Particularly important points are:

* Hibernate is suitable for reporting. You can write queries with aggregation, projection, subqueries, etc. People even use HQL from Jasper Reports!
* Hibernate fully supports detachment and selective reattachment of persistent object graphs. This means you don't need to write data transfer objects in a distributed architecture.
* Hibernate provides runtime fetching strategies, fully integrated into the query facilities, allowing you to finely tune exactly how much data is retrieved in each query.
* Since Hibernate is not trying to be too general, we expose some lower-level features of the relational database. For example, pessimistic locking is supported via the LockModes, the Query APIs support query pagination and now also multi-region query caching, its easy to mix JDBC and handcrafted SQL with Hibernate code in a single transaction.

Of course, JDO2 tries to catch up to us on some of these things. But its hard to catch up to a target that moves faster than you do.

A further advantage, that may or may not be important to you, depending upon your development style and environment, is:

* You don't have to implement a mandatory interface or enhance your code in the build-process - and you don't need control over classloaders. Hibernate allows for unmatched portability of your unmodified plain Java classes.

Hibernate is open source

You'll find all the great things about open source software here:

* helpful user community
* rapid bugfixes (we aim for < 48 hours)
* rapid releases
* open to suggestions for improvement
* project is driven completely by developers, not marketing types
* we love what we do
* no "vendor lock-in"; you have the source!
* huge userbase, which means that you can be confident of the quality / robustness (we have a bigger userbase than any other ORM vendor)

Hibernate has all the advantages of commercial software, too

We have our cake and eat it:

* good free documentation and a book on the way
* backed by a commercial support organization bigger than any of the ORM vendors except for TopLink
* one fulltime developer already, hopefully more to come

Signed:

Gavin King
Christian Bauer
Max Andersen

Thank you Gavin for all your answers!

I will dig deeper into Hibernate in future.

Hibernate was quite easy to use with the Eclipse plugin. And the documentation was good too.

I believe that you are convinced of what you do AND that you are very good in what you do.

Hibernate has one very good cook instead of many medium cooks. This means conceptual integrity which is important for good software.

I had to laugh when I read: "But its hard to catch up to a target that moves faster than you do."