Hi Nick,
> 1. One of the goals of JAXB (as defined in the spec) is to
> circumvent SAX/DOM by allowing applications to access XML data
> directly via Java objects. But the new Java APIs generated by
> xjc still have to be incorporated into your application. I'm
> not sure if the effort is going to be less than using SAX/DOM's
> API since most people are familiar with the standard. If you
> design an application from scratch, your application will be
> bound to the schema and JAXB APIs. So if the schema changes, you
> have to modify and recompile your application, whereas it
> wouldn't always be the case if using SAX/DOM.
When you read an xml document in java you take the data that you find, and
either create objects with it, or pass it to objects; in either case you're
giving it to objects that will internalise and encapsulate it.
If you just use the data directly then you're not developing in the OO
paradigm, and perhaps shouldn't be using java. If you're just taking the
data, and creating new xml documents out of it, then you should be using
xsl. But, if you are writing an OO system, then you'll want to put the data
into domain objects - objects that model the solution domain of you system
(classes like Customer, Address, etc).
Right now you're writing DOM or SAX code to read the xml document, and
writing code that takes the resulting data and puts it into the domain
classes. This is what JAXB does for you. It creates entity classes that you
can use from your domain classes.
Your schema may change, but your domain model will probably remain fairly
static. In this scenario, when the schema changes you'll generate a new
entity model and make the relevant changes in your domain model to access
it. This could be as simple as changing a single attribute name. If you
were using DOM or SAX then you'd have to change a lot more, write tests for
it, run the tests, fix the implementation, run the tests again, refactor,
etc.
There are other benefits too. If you *can* assume that the JAXB
implementation you're using generates defect free code, then you don't have
to spend time testing that code, and you don't have to look there for
defects when they arise in your system. Everything you write by hand you
have to distrust, test, and continually confirm.
The arguments for using JAXB over DOM or SAX where a schema is available
are persuasive. I can find no good reason to directly use DOM or SAX again.
> 5. Does anyone acutually use or consider using JAXB for
> applications? I'd really appreciate if you could provide some
> insider thoughts.
I'm writing a Jabber client, and am generating the entity model based on
the published schema. One problem I am running in to is change. The Jabber
protocol gets changed more rapidly than the schemas are released, and this
causes some difficulty. JAXB doesn't behave itself in a desirable fashion
in the face of nonconformant data. However, I'm convinced that the
headaches caused by this are fewer than the headaches I'd have trying to
write the equivalent code by hand. I know that if I had to write a fault
tolerant xml mapping layer for this tool then I'd not bother.
Once the client is working we're going to use the knowledge that we've
developed writing it to start creating smart bots (actually, expert
systems).
I've also written a v.small application for an article for DevX that will
display a play (in the article it's A Midsummer Night's Dream), in a simple
SWING gui. It took me about 3 hours to knock it together, and most of that
time was spent formatting the display - reading the document and navigating
the resulting domain model was trivial - and as the schema I'm using is
stable I don't have to worry about change.
Cheers,
Bryan