OJB, Hibernate and the Cage

I have been working for one company for the past 2.5 years and back about 3-4 years a go. The ORM platform chosen was OJB. Now Apache OJB (from the DB Project) had quite a potential lead in the ORM world.

It was logical in it's design, goals for JDO compatibility etc. (it made them all).

Over time, users waned and moved over, or took up hibernate. Hibernate having the market share takes the cake now for

1. Performance
2. Configuration Ease
3. Options
4. Assistance
5. Stability

and last and NOT least

6. Plugability

This is OJB's main killer.
In my 2.5 years working with it I can honestly say that it is the worst Java library I have ever used, ever had problems with, and more than ever passionately wanted to move off.

Now this is not a diss to the authors of OJB. By all means, they did a great job. But some things just died in there and before you know it, the project is like a car running on rims with no tyres trying to drive the nullabor. Just ill equipped for a big task.

My main pet peaves for OJB are the following

1. Class loading issues

Deep in the bowels of OJB it all starts with an OJB.properties file. This is the beginning of a painful end. OJB locates this from the classpath and then inside this properties file, locates youre repository.xml file (akin to *.hbm.xml).

Now, the repository.xml has all the settings for the mappings, but it also requires you to declare you datasource (can be a JNDI) but also transaction demarcationb (the OJB way) and a few other nasties.

Coding MUST be done such that infrastcuture is a side concern. ? What do I mean. Write your code, but write it like it;s on an island. Don't include code, logicthat binds you to a database, or a way of communicating across the wire.

This classloading issues gets ugly in many ways. It I wanted to merge repository files together, I have to do this by either, writing an adaptor class to join them all up or .. just hand (or ant,maven) hack them together.

But .. remember, a repository file is for one database.. how do you do two databases ? (seperate schemas) ..

Know, that we worked it out .. how, by ensuring that one OJB for one schema was in a sibling or seperate classloader.

2. Inconsistencies between versions (minor versions)

The Apache Portable Runtime project has a very nice succint way to describe versions. http://apr.apache.org/versioning.html
OJB certainy did not follow any of these guidlines.

The library is still stuck on 1.0.4, 1.0.2 is about 3 years old and 1.0.3 was just skipped because it was full of bugs (for us).

OJB 1.0.4 seems stable enough, this was after a massive code change that occured to our base product to make it work.. oh the pain.

Now the observant among you would say that you shouldn't have to change code if you change your ORM tool. Sadly we had to because of the legacy Java Code, but even still. There was horrid work to be done just trying to work with the incompatibilities.

Why upgrade then ? Well we found some things didn't work in 1.0.2 (something with key Sequences and Sybase (yes another groan, see my Sans SQL Post) and 1.0.4 supported it.

From the site itself (on the news section)

12/2005 - OJB 1.0.4 released

Contains bug fixes and new features. For more details see release-notes.

Argh ..

3. It's just plain dead

The site is tumble weed city. Everywhere you look on OJB it just smells of a house that is falling.
Where I work(ed soon) we have a large application that relies, depends, is hard coded to, OJB, it is an inherited platform and we now know what not and what to do with OJB.

Some initial analysis has gone into the replacing it with Hibernate, but a lot of the other code is going to be shelved so it is almost not worth it now.

All the new work has a clear separation of ORM and Domain so that way it can easily be shifted in or out as you see fit. (thanks Spring).

I think the project (OJB) is dead, or should be left alone.
The mailing lists are a dieing world.
http://mail-archives.apache.org/mod_mbox/db-ojb-user/
Summary

Why did I mention hibernate in the title ? Well, Im never using OJB again that is why.

OJB users now and future, your mileage may vary, because you might now how to make OJB work sanely. The thing is, it was not obvious to me or about 6 other developers I worked with who also have a bad taste in their mouth from this seemingly harmless library.


Have fun, and keep the code away from the hardware :-)