Alexis's Blog on TReCX

The fact that hyperjaxb2 is linked to from the main JAXB page is probably what led us into thinking that it was a good project to use initially. It may well turn out to be brilliant one day, but it was proving to be not exactly straightforward to use. In the mean time we had outcomes to produce and using JDO just seemed like a better option to get stuff up and running. This post outlines some of the pros and cons of the two approaches and hopefully gives some idea as to why we're now using JDO.

hyperjaxb2 (cons)

• one-man band effort.
• partially documented.
• "straddles" 3 technologies (and thus documentation!).
• uses older JAXB (JAXB 1.0).
  

JDO (pros)

• well maintained.
• well documented.
• standard API (rather than library). Therefore, leaves open the possible option of using a commerical (superior?) implementation instead.
• tools support; Eclipse plugins and Ant tasks.
  

In practice I was finding that when working with hyperjaxb2 I was having to have 3 pieces of documentation open at the same time; hyperjaxb2, Hibernate and JAXB 1.0! This is because it is a composite process, specifically, it consists of enhancements to the JAXB schema generator that uses Hibernate to achieve persistence. As I've posted previously, in terms of clarity there really is no comparison between JAXB 1.0 and JAXB 2.0. There are plans for hyperjaxb to use the latter (the confusingly named hyperjaxb3!), but this is even less mature than hyperjaxb2, (which itself is only version 0.4!) and does not have any binary releases yet.

What I like about JDO (we're using the reference implementation JPOX incidentally) is that XML and persistence stages are quite separate. What we do is use JAXB to generate classes from an XML schema. We then give those classes to JDO which makes a sub-set of these classes persistence-capable, as specified via a mappings file (package.jdo) through a process of byte-code enhancement. This persistence-capability is effectively transparent in the sense that no (public) methods are added to these classes (unlike hyperjaxb2 which for example adds a primary key method to each persistable class). We can then use these same artefacts to drive the automatic creation of the relational database schema (from a choice of vendors, naturally!). Just like Hibernate it has it's own database agnostic query language, in this case JDOQL. This makes it easier to switch database vendors without needing to change the application itself. The main motiviation we had for doing it this way, is that it should be easier to alter the event XML schema (which is far from cast in stone!) and then automatically generate all the downstream artefacts without too much thought.