Sunday, December 4, 2005

Adventures in Java Land: JDO

Since I decided I wanted to learn some more about J2EE development, and everyone seems to agree that there just aren't any decent intro books on it out there, the only remaining way to learn seems to be to just do it.

So I am. This weekend I started work on a small web app written in Java. It's a basic, bare bones bug tracker, with JSP and Servlets for the view and controller portions and JDO for the model. So far all I've really been doing is the model part, so I've basically been playing around with JDO.

I can't help but compare JDO with ActiveRecord, the ORM portion of Rails, since it's really the only ORM system I've spent any real time with.

JDO (specifically a JPOX 1.1 beta, which implements the JDO 2 spec) seems to let you do a lot more than ActiveRecord does, but with that comes extra complexity. Now that I've wrestled with it a bit I've managed to come up with something that does what I want, but it took a bit more work than it took me to do similar things with ActiveRecord when I first started playing around with it. I suspect it's partly because ActiveRecord comes with a LOT of good tutorials. JPOX has some great docs, but it seems to be a bit harder to find the parts of it that apply to what I'm trying to do, largely because it does so much.

I'm not overly thrilled with the way JDO duplicates info, you write your Java classes, then you create a metadata XML file that defines how they map to database tables. An "enhancer" tool then reads the XML and magically adds the code to your classes to support persisting you objects into a database. In JPOX you can even use a tool they provide to create the database schema from your JDO metadata, which is pretty much the opposite of how you do things in ActiveRecord, where at least I tend to write my database schema first, then build my Ruby level objects around it. You don't have to do it this way in JDO of course, it's flexible enough that you can work from either direction, and I imagine starting from the Java and JDO metadata would break down eventually once you need to make changes to an existing schema, but it's reasonable for getting started.

One thing I do see as a problem is that it's difficult to tell from the JDO metadata exactly what kind of SQL schema will be created. I suspect you need to have a pretty strong grounding in the details of JDO before you can really be in a position to make incremental alterations to your application's data model.

I'm pretty much convinced that the "right" thing to do about the duplication of effort is to move the JDO metadata closer to the Java level objects. Apparently the way this is usually done in Java land these days is via xdoclet, and I'll probably investigate that eventually, but what I really want is JDK 1.5 annotations a-la EJB 3 persistence, which looks quite slick, but of course isn't really available yet. It is nice to see that the state of the art in Java land appears to be moving in a good direction though.

Anyway, now that I've got a workable data model I'll probably look at fleshing out the controller servlets and JSP views next. That'll give me a good idea what needs to change in my data model to make it really useful in an application.

3 comments:

  1. try hibernate. hibernate/ejb3 and jdo take two different approaches to the same problem:
    JDO -> compile time instrumentation
    ejb3/hibernate -> runtime instrumentation
    i've found hibernate to be more flexible, but ymmv. also, the jdo team has merged with the ejb3 team and it looks like jdo is going the way of the dodo in the next few years.

    ReplyDelete
  2. At work we use Kodo JDO. It works, and is both flexible and complex. The thing I dislike the most about it is the duplication of information, in as many as three places: the Java code, the metadata, and the schema. I don't particularly care for build-time bytecode enhancement, either. For projects where I have a choice, I tend to use Hibernate. The latest version of Hibernate has support for EJB3 annotations, which I've played around with a bit. They seem promising.

    ReplyDelete
  3. reply to jfarley: I'm not sure why JDO would go the way of the dinosaurs, why would everyone want EJB apparatus in their apps when for example it's a client side app. Also, JDO according to some tests is 4-5 times faster than hibernate and has a business friendly license (JDO's Apache vs. Hibernate's LGPL).
    I think that JDO is here to stay.

    ReplyDelete