Alignment: Chaotic Java

Tuesday, December 13, 2005

X2J on the firing line

I've been getting more than one comment about the X2J project I've introduced here and other projects, specifically XStream and XMLBeans. I wanted to clarify the differences (at least the ones I see) between the frameworks to what I intend X2J to be.

The X2J framework, according to myself and the SourceForge title it holds, will "...performs serialization and validation of POJOs to XML, XML to POJOs, POJOs to XSDs, and XSDs to POJOs using Annotations", i.e. will replace the usage of XML Schema Documents by using Annotations. Let's be clear about it - Using X2J means no XSD files needed - You write your own classes, annotate them, and then you writing and reading your data into and from XML documents. It is a binding tool that doesn't use external XSD files for the binding.

You can read about binding tools on a coverpages article about JAXB. To be brief, they state that a binding tool helps "...(1) unmarshal XML content into a Java representation; (2) access, update and validate the Java representation against schema constraint; (3) marshal the Java representation of the XML content into XML content. JAXB gives Java developers an efficient and standard way of mapping between XML and Java code...".

(Yes, I am aware I am shooting really high with this :-) )

Now, about the other frameworks. This is what I understand these other frameworks are meant to do. XStream is a serialization framework. As they say themselves in their FAQ:

Can XStream generate classes from XSD?

No. For this kind of work a data binding tool such as XMLBeans is appropriate.

XMLBeans however is a data binding tool. The way it achieves it is similar to Java Architecture for XML Binding - JAXB. It uses an XSD compiler - scomp - to generate a .jar file containing their pre-compiled XML Schema Object model. Obviously they do a lot more and in some cases a lot better than JAXB, which can be fully read on their Overview page.

The major difference between XMLBeans and X2J is in the binding method. XMLBeans make use of the XSD files; Whenever these files change, they need to recompile their Schema Object model. While this simple compilation process doesn't frighten most of us who know how to use ant, my problem with it is the writing of the XSD files themselves. They are complicated, redundant (as you have the same data structure in your code already in most cases), and hard to maintain (single file for all the data model, instead of the separate Java classes you already have).

The reason behind X2J was to eliminate the need for XSD files, for their complexity and redudancy, and maybe come up with a better way to do XML binding. I would be happy to contribute and join a larger framework - But some are just working on different paths than what I intend X2J to be.

Hope this clarifies some things. I encourage everyone to stand against my words! (or maybe even suggest cooperation?)

Related topics


Post a Comment

Links to this post:

Create a Link

<< Home