We all know the story. Objects and relations are like oil and water. Java tries to mix them, with varying results.

First of all, what is the deal? On surface tables look simpler. Each row as some elements (say class variables), and an ID (say a pointer to it). Things get complicated with foriegn key constraints (links between classes). Try implementing a tree in relational schema and you understand the pain and suffering.

There is a myth around that SQL is difficult. I would not say it is difficult. I would say it is chaos (like in chaos theory). A simple change in the statement can cause inordinately large change in the execution time and semantics.

Anyway, the famous idea is that there is impedence between the database and programming. You normally program in Objects and store the data in relations. It is problematic for many reasons:

1. It involves lot of manual work to get and store the data in the database from objects.
2. Your relational tables may be setup for different constraints. For example, if you have a linked list as object, your relations do not look anything like it.
3. Performance constraints are different.
4. Your domain objects and relations could be very different.

So, to reduce the pain of programmers we want to reduce the impedence between relational and object world.

We have several choices:

1. Adding object features to the database: There are excellent Object Databases that rival relational databases and provide great performance. Unfortunately, they don't have good market share.

   On the other hand, companies like Oracle started supporting Object relational databases. Those features still are not popular.

2. Adding databases to the language: So, they added DB like features via libraries. There are any number of embedded DBs, some operating seamlessly. They are easier to write in java. Some of them are: http://www.hwaci.com/sw/sqlite/ and http://hsqldb.sourceforge.net/
3. Building a bridge between Java and RDBM: This is our main interest. There are several choices and we will examine them below.

So, for reasons that have mainly to do with intertia, I think the 3rd one is the only real alternative at this point for a large number of projects. Here too, we face several options.

Initially, there were no standards in this area. So, there were some products that sprang up. Eventually, Java came up with JDO. Now, there are new products that support it. I will try to talk only about free or near free products here.

1. Castor: This is one of the oldest projects. The new incarnation claims to support JDO. But the performance is questionable. From what I have seen on the net, I am not sure this is the best current choice.
2. OJB: From Apache project. Supports JDO. Still somewhat new.
3. Hibernate: Seems well designed. Has lot of third party support.
4. Torque: From apache. Not for JDO. Mature.

Again, except for Torque, the rest are object centric. That is, they use Oracle or any DB of your choice for persisting Java objects. Torque generates code (classes and methods) to map relations to classes.

Here is a link that seems to talk about these:
http://www.mail-archive.com/torque-user@db.apache.org/msg00792.html
Let me quote from it:

Torque is more database-centric. You use the Torque-generated objects in a database-like idiom. You can touch foreign key IDs directly. You need explicit mapping objects for many-to-many relationships, as objects/peers and tables always match 1-to-1.

Hibernate is more object-centric. You can't touch foreign keys directly, and you don't need map objects for many-to-many relations. Hibernate can handle the concept of ordered collections like Lists in the database, while in Torque you would have to maintain the sort key yourself. It does cascaded updates/deletes natively, while Torque relies on the database's native support.

These extra features can either be a blessing or a curse. There's a much steeper learning curve for getting it all straight, and there are lot more options for configuration. On the other hand, once it's up and running, it is very powerful. Also, you may sacrifice some performance for the stronger abstraction layer, especially with many-to-many relations. For example, in Torque you can just say "add mapping from an A to a B" as the A-B mapping is itself an entity. But in Hibernate you have to load all the As, load all the related Bs (at least the IDs for them), then add the B to the collection.

things that seem to be purely advantages to Hibernate (same goes for OJB and Castor):

1. use of POJO (plain old java objects) for data model means data model is not coupled to persistence layer, and can be used in different contexts (e.g., return value from SOAP service)
2. bind variables and prepared statement used by default
3. object query language
4. persisting collections of "primitive" non-entities (e.g., a List of Strings). Lazy-loading tends to work better.

On the other hand, if you want to make a quick prototype, Torque is easier to get going with.

I've also looked at Castor and OJB, and it looked like Hibernate was more active and better supported. Hibernate doesn't attempt to solve the JDO problem in general, but it is specific to relational persistence and does that one job pretty well.

Please go ahead and discuss.