JAXB is an interesting parser generator. I used JavaCC 5 yrs ago to generate some Java classes from a grammar defined for some COBOL copybook. It is a similar idea but the grammar is called XML schema now.
Let me explain why JAXB is a bad idea in the following case of parsing XML. This is a real world example.Imagine a XML stream (in my case reading from a remote MQ queue via MQI) is represented in a tree data structure. According ot its schema,there are at least 6 levels nodes from the root to the leaf node.
At first I started to parse the XML using JAXB as a natural solution . This is natural due to the generation of the XML is done by JAXB.
For the application I designed, only portion of leaf nodes are at interest. Using JAXB generate a zillion of Java objects in my Eclispse workspace. The worst is I need to perform java "null"checking for every intermediate node along the path to the leaf node I am interested. As a result, the code got bloated as well as hard to read and maintain.
Then I sit back and thinking it looks ugly.I’ve realized it is how to access the data matters, not the structure (objects). DOM/XPATH should be used for just accessing it. It is dynamic and XpathAPI can be wrapped like a hash table look up .Not sure if any JAXB 2.0 can use XPath. Even if there is, the benefits that brings by JAXB is won over by the simplicity of DOM/XPath. In this case, I am not interested in huge object tree generated by JAXB. So I changed the code in a day to use DOM/XPath and added a few DAO object whenever I need it. It looks and works beautifullly now. Simple is better indeed in this case.