News: Comparing Java Data Binding Tools
Mette Hedin has written up a comparison with some of the top Java XML data binding tools that use XML Schema. The article discusses the different tools, goes through the test suite and results, and puts up a feature comparison of the various projects. This by no means is a comprehensive list, but is a good start to understand what is out there.
- Posted by: Dion Almaer
- Posted on: September 08 2003 09:03 EDT
Read: Comparing Java Data Binding Tools
What other tools are you using?
- Comparing Java Data Binding Tools by Tero Vaananen on September 08 2003 09:33 EDT
- XMLBeans by Jon Ridgway on September 08 2003 11:40 EDT
- XMLBeans by Kris Schneider on September 08 2003 15:42 EDT
- XMLBeans - footprint comparison by Leoš Literák on September 09 2003 05:17 EDT
- XMLBeans by Kris Schneider on September 08 2003 15:42 EDT
- Authors bio by Trevor Cook on September 08 2003 11:43 EDT
- Comparing Java Data Binding Tools by Parag Gandhe on September 08 2003 11:45 EDT
- Comparing Java Data Binding Tools by John Davies on September 08 2003 13:25 EDT
- Try a schema for an X12 specification, they'll choke. by Will Gunadi on September 08 2003 14:04 EDT
- Try a schema for an X12 specification, they'll choke. by John Davies on September 08 2003 17:24 EDT
This comparison is written by a woman, I believe.
Thanks. Bad assumption. The message has been updated to be neutral :)
Did you figure that out from the parts in her blurb where it says
She has several years of experience in XML data binding development
Currently she utilizes her detail knowledge of XML specifications for Black Pearl.
Try focussing on the content of the comparrison. The authors gender is totally irrelevant.
As a BEA customer I have been looking at XMLBeans, I currently use Castor; I understand that XMLBeans out performs Castor & JAXB. Are there any benchmarks that cover all three? Also when I last looked at JAXB I found classpath issues within EARS on a number of application servers; anyone know if these have been fixed?
There's some information here about XMLBeans performance and schema compliance:
I would love to see comparison of various projects not by speed, but by memory, they consume. My website (www.abclinuxu.cz) uses XML as holder for all data. Currently I use DOM4J, which is great from programming perspective. But when I cache 5000 objects, memory footprint matters. Will be JAXB or XMLBeans better from this perspective?
You can see a comparison between dom4j and several data binding approaches in a developerWorks article I wrote that includes both speed and memory usage. The devWorks article covers a wider range than the article discussed in this thread, since I included both mapped and code generation data binding approaches and also used dom4j to give a document model comparison.
Data binding approaches generally (if they're done right) use much less memory than document models. They can also be very fast. JAXB delivers decent performance for a code generation binding approach, while my own JiBX framework mentioned elsewhere in this discussion gives the best performance of any binding approach I know of. JiBX uses mapped binding rather than generating code from a Schema, though, so it's not as easy to work with if you're starting from a Schema.
As far as XMLBeans goes, I haven't yet tested it out for performance. I wanted to earlier this year, but at that time it was still under restricted licensing and BEA would not allow a benchmark. I have been in several discussions with the BEA developers, though, and have a good understanding of how it works. In terms of memory usage, XMLBeans will be a compromise between a document model such as dom4j and an efficient data binding approach such as JiBX (probably somewhere close to the midpoint between these two, in fact). This is because XMLBeans actually stores the entire set of parse events that represent the document in memory. XMLBeans is very fast for just reading and writing documents, but if you actually make heavy use of the data binding features (which you don't need to use - XMLBeans offers the most flexibility in processing of any of the frameworks) it's going to be considerably slower than JiBX and probably slower than JAXB. This is because it does a "live" mapping between the objects and the underlying XML store. In summary, XMLBeans is a very elegant approach in terms of flexibility, but not the best for performance or memory usage.
That was interesting thanks!
I'm surprised gender has been brought up but the fact that she is the lead developer for XGen (which surprisingly turns out to win hands down in her "comparision") hasn't been mentioned ...
I'm surprised gender has been brought up
I guess mentioning that the author is a woman makes this inevitably a gender issue, regardless of my original intent to point out an error in the original post, which implied that the author was a man. I should not have left the room for other spontaneous conclusions (which in their own right are quite revealing), for which I apologize.
I have to say this seemed pretty biased towards XGen to me.
For example, "Customization Disallowed" is included in the feature comparison chart as a "feature", for which XGen gets a nice green tick and the other tools get nasty red crosses.
Claiming that lack of customization support is a "feature" is a wonderful piece of spin. I'm looking forward to other features such as "unhurried execution speed" and "varied, unrepetitive output". :-)
This is a very good article and a nice attempt to promote Xgen.
Even today, we face lot of problems in XML parsing and processing and this article has highlighted few of them. The best part is that author has also written a new open source tool that attempts to solve these problems. Authors comparison of tools is based on features of the tools and design time issues. It will be very good to see how it really performs for example, cost of marshalling in a multi-user and concurrent manner.
If this new tool, XGen is thread safe and performs well, then I will be happy to try it out.
Well since this thread is about promoting XML Binding tools, why not have a look at C24's IO. It is based around JAXB and Castor but with a financial services slant to the product.
Sadly it is not free, I'd love it to be for the moment it isn't. What you can do is to import DTDs, Schema, XML instance data and Java Objects (and database schema). It will then allow you to change the data model, if you need to using the graphical tool, the IO Editor, and save it into CVS (or similar). Using the data model you can then generate and deploy stand-alone Java code together with a generated ANT build file for building it all. The "IO Editor" is the only bit you pay for, the generated code is your to do with as you like (i.e. license free).
We have tested it with FpML, FixML and several other financial services *MLs and have several large referencable customers (all banks and clearing houses) in the UK, mainland Europe and the US.
It really comes into its own though when you come out of XML, there are lots of nasty message types in the banking industry that are just not definable by XML Schema. The definitions go way beyond the capabilities of Schema and into the realms of the banking business. This is where IO becomes a "no-brainer", there is no way any programmer can code a fully validating Java (or C, C++, VB etc.) API for a SWIFT message in under a two weeks, it is just too complex (an article about parsing SWIFT). Some of the messages are so complex I'd place an open bet that no one could code one up from scratch in under a month. C24's IO can generate Java code for every SWIFT, OASYS Global, FIX, CREST, EBA etc. etc. message. Oh and by the way there's a mapping GUI that will also result in deployed code.
For XML on it's own it's probably overkill, plus the fact that it costs money doesn't really place it in the same ball park as the likes of Castor and JAXB. However if you are working with XML versioning, work-flow, several other message forms (not just XML) and want transports like JMS, DDL (SQL) etc. build in then please check it out.
We're open to benchmarks too, we've been working with Sun, Sonic and Gigaspaces to get the ultimate scalability and performance.
I've read and enjoyed the article, and I particularly appreciate the author's up-front acknowledgement of her part in the XGen project.
XML data binding is an increasingly important technology and the focus on it here is welcome. However, always bear in mind the "XML Silver Bullet" anti-pattern - don't just use XML everywhere for XML's sake. Use it wisely.
I'm consulting for a Bank in the city of London. We have a substantial requirement for XML and other messaging. On the external interface side our Java team has to receive, process, and transmit SWIFT messages. We also have our own XML standard for trade messages (SWIFT, for those unfamiliar with it, is not an XML standard), and more than a passing interest in FpML.
We are using IO from C24. As John Davis has pointed out this is not a low end tool. Our use of it is extensive, and it makes managing the SWIFT interface a breeze. You won't find many Java developers saying that about SWIFT messaging.
We also use C24 to build the models of our XML message catalogue. Although C24 can import XML Schema, we prefer to build models of messages in the C24 IO user interface and then generate the XML Schema and the supporting Data Transfer Object (DTO) classes. Generated classes have generic accessors which follow the structure of the XML messages, and also expose appropriately named and get/set methods at appropriate levels of the structure so that developers can hand-code against a typed interface, instead of the having to use the less strongly typed generic API. Best of both worlds?
I'm also using C24 IO as a modelling tool to build the XML Schema for the JDO 2.0 object/relational mapping descriptor. In this case I'm not generating Java classes, since these are not required, but the user interface makes XML Schema very easy to model.
I'll happily discuss C24 IO further with any interested parties.
Kind regards, Robin.
Robin M. Roos
Ogilvie Partners Ltd
Here's another tool which I have found to be very useful. It's called JiBX and you can get it from:
JiBX does not care about XML Schema. Instead, JiBX is perhaps the most flexible tool for mapping Java objects to XML instance documents. You might be able to cite the XML Schema location to be put into the instance documents, but this is fundamentally a different approach from using XML Schema as a starting point and generating Java classes through automation.
JiBX is particularly interesting on three specific counts:
1. It uses bytecode enhancement to add XML generation and parsing capabilities into the bytecode of the Java class, so it is very fast.
2. It employs a Pull-Parser approach for XML parsing, so it is very fast.
3. It does not tie the Java class to the structure of the XML document. Just because an element lives within another element in the document, does not imply that the data contained in the sub element must be an equivalent level down in the Java structure. This allows the deep XML structure (which makes sense in XML) to be mapped easily to a more shallow, but not necessarily flat, structure (which makes sense in the Java object model).
I have found this flexibility to be extremely useful.
Kind regards, Robin.
I tried both JAXB and Castor, both of them can't handle the complexity for schemas that map to an X12 document specification.
For those who don't know what X12 is, go here: http://www.x12.org
I've seen it being used (or about to be used) heavily in multiple industries (Healthcare, Transportation and Logistics, Mortgage, Financial Services, you name it), so this is not a small niche problem by any means.
1. Castor: Can't handle nested replicated element names.
Castor also has problems collecting different xsd:enumeration values (it only saves a few, not all). This results in it not being able to validate incoming xml that is actually valid.
2. JAXB: JAXB has a problem with deeply nested (and large) xsd because it creates String constants (containing a serialized "schemaFragment") for each class that it generates. Resulting in 250Kb long String constants that is promptly rejected by JVM class loader.
UPDATE: I tried the latest version and this time it got through parsing, but it breaks down with StackOverflowError
Another thing with JAXB is that we have to install the Java Web Services Developer Pack 1.2 which replaces some of the standard jre libraries with "endorsed" ones. If you want to have some fun, try running stock JBoss with that in place (that is, if you consider pulling your hair out of frustration *fun*).
I fired off questions to their respective web-support teams, and got nothing useful out of them.
So, one can surmise that my experience with Java Binding is not that great.
I hope this posting will be some kind of a wake up call. It's easy to test your libraries with a couple of trivial examples, but try it with the real problems out there.
We've not had much call for X12 in the wholesale banking market but I agree it's a very widely used standard and would be worth doing. I've had a poke around the X12.org web site and even registered but I can't seem to find an XSD schema. Does the licensing allow you to email/post me a copy or perhaps you can point me in the right direction to get hold of it. Since we (C24) don't generate Java code directly from the schema we're not restricted by JAXB or Castor limits. First we import Schema using some of the Apache/Sun schema code into our own data models, then we generate, write and deploy the java code from our model, not the schema. We can do the FpML schema quite "easily", i.e. it takes seconds but I'd really like to try out X12.
We still come across problems from time to time but since we charge for the generator we can invest time and effort into fixing them, we've also got a number of banks and clearing houses using the code so it gets a lot of use in production.
I'm curious, is the XGen in the article the same as the one I worked with in the late 90s from CSK Switzerland? http://www.csksoftware.com/xgenoverview.shtml.