How do you perform java <-> xml binding (marshalling and unmarshalling)? There are many options such as: Castor XML, JAXB or XmlBeans, XStream, JiBX, and many more. What does the community feel are some pros and cons? What experiences have you had?Joseph Fouad's Opinion
XML has become something that we deal with on an almost daily basis.
CASTOR (http://www.castor.org) is the first to address the problem so i expect it enjoy a huge user base, actually castor is a terrefic piece of software and its standard counterpart are TWO JSRs (JDO,JAXB) so the benefits of its use are obvious database<->java object<->xml which fulfill the needs of any MVC developer;
Database for the domain(actually a good ORM solution)
java objects for the controller
Xml for the view( +XSLT )
and never forget that we are using a single tool so no need for a very long training and the castor team make it even easier as u can make the ORM and XML binding in the same configuration file, which is xml based,but the good news that there is several GUIs for it
BEST of all ,it is free and even BSD style license
but castor is not standard in term of jcp, ie. not a JSR and i know that several organisations never consider anything not a standard (yes, they even prefer a buggy home grown solution on non standard lib )
it comes bundled with the sun wsdp, think of it as a copy of castor xml in a standard JSR , actually no real xml binding features and of course no DB support (you have to use Entity beans or jdo etc if u need it)
It is not opensource (an open implementation is undergoing incubation at APACHE FOUNDATION)
it is not a requirement for J2EE complience so may be your vendor miss it it seems to me that it is not mentained or the it will take long to evolve due to long JCP cycle
BUT remember it IS the standard
ok first of all , it is developed after all these solutions so expect it to address there short comings
second ,it is developed by BEA which in direct contact with the developers who needs it and it enjoy the BEA support in their IDE or technical support team
third,the development continue at APACHE, so their is a huge comunity for it(you are not alone) , and ensuring comtinous development fourth, it preserve the underlying schema when converting to java so it ensure no data or structre loss
fifth,a whole bunch of tools to assist you in development, and the second release will contain more such as instance to schema and the reverse sixth, it is opensource with apache style license and much more....
but no database support AND if u are not WebLogic user then this is not a standard part of ur development
ok that was my opinion and i am looking forward to read yours
If you want to do XML binding then why not use C24's Integration Objects (IO)
, it's free for non-commercial usage. Based on Castor, years of work have gone into improving the areas of schema not supported by Castor and JAXB, it has over 2,000 JUnit tests from instances, tests and benchmarks found over the years.
To double check the support, all test schema are read in and a model generated, a new schema is then generated and compared with the original at a binary level. The same is done XML instances, i.e. they're read into the generated Java objects, serialized and de-serialized. The XML from the de-serialized object is then binary compared with the original instance, i.e. full round-tripping.
It was originally designed for SWIFT, a complex standard still used in virtually every bank on the planet, its XML support is largely aimed at FpML, another financial services standard and probably the most complex XML schema known to man, so complex in fact that only the latest release with patches of leading products like Sonic Studio and XMLSpy support it. C24-IO includes an advanced meta-data repository for FIX, ISO-15022, 20022 and FpML ontologies (pro version only).
While it is probably more complex to use than JAXB or Castor it does provide a lot more, firstly you get a GUI which includes data modelling and transformation. From DTDs, XML instances or XML Schema it generates Java classes, these have a vast number of options including bean classes, packages, interface generation, code optimisation and customised serialization, all this is tied together with a customised but customisable ANT file. Other options available at a cost include a model diff tool, CVS, SVN and ClearCase support, Hibernate support, model versioning, ant tasks for automated generation and XMI support.
This is used in most of the largest banks and clearing houses in the world, some have even gone as far as defining their entire internal messaging systems using this tool. It's been in production for several years and has $billions worth of trades going though it every day.
Worth a look at least,
Sorry but the question asked about XML binding tools, C24-IO is an XML binding tool and can be used for free, why shouldn't it be plugged?
you bad man
Sorry but the question asked about XML binding tools, C24-IO is an XML binding tool and can be used for free, why shouldn't it be plugged?
John signs his real name.
Cameron PurdyTangosol, Inc.Coherence
: Shared Memories for J2EE Clusters
Sorry but the question asked about XML binding tools, C24-IO is an XML binding tool and can be used for free, why shouldn't it be plugged?-John-
From what I understand, it can only be used for free for non-commercial applications. I believe that most of us are developing commercial applications, not hobby projects.
I, as probably any developer, had been looking for a XML<->Java binding tool. After a research I decided to use JiBX (www.jibx.org). It is open source, it works very well, it is very easy to use and transparent to the developer. It is also one of the most flexible XML tools I met. This was for me a crucial point, since everytime you start doing something serious, you always need to divert from the standard usage of the tool.
I really advice to have a look at it!
Stefano Fornari - Sync4j Project Manager / Funambol CTO
Sync4j - The open source SyncML mobile application platform
i dont know if the author ever checked it. but u have check ll of the non commercial ones (betwix,xml beans etc.) and my conclusion was that xstream was the best. i was looking for rimtime binding rather than compilation time binding. this tool gave me all i need with good flexibility. only downside is not a strong community (but that goes for all other opensource runtime binders) and some bugs.
xml and java belong to 2 different paradigms as java and rdb(relational database) do. java classes have data field (attributes) which can be expressed in xml/rdb.In this aspect, xml resembles to rdb as a data container.
so the binding means to establish relationship between the java class data fields and the data unit in the data container. In rdb, data units are tables, colums, rows and etc while in xml data units are elements, attributes, namespaces, text and etc.
as everyone knowns hibernate is a good orm tool, it implement the mapping with out much additional requirement just for the mapping. classes and db schema can be developed 'independently'.
So ,i think, a good xml binding tool should share the same properties. "start with the schema (XSD) of the XML, generate Java classes out of it, and then at runtime you can convert the real XML data to Java object back and forth" is not a good idea. So I vote for jibx. it uses and xml configuration(resemble to hibernate mapping files) to described the relationship between the 2 paradigms and implement it use bytecode manipulation to achieve good performance. It allow the java class and xml schema to evolve independent.
Of course, jibx now is not perfect. but, I think, it's the right direction.
...and embrace PL
!PL provides a simple format to serialize object graphs into a textual representation, coupled with a set of standard data types as well as a free and open source implementation.http://alt.textdrive.com/pl/
Same here. I use XStream for all sorts of stuff that has to do with Java and XML, and it's fast, it works, easy to configure, easy to fix tricky things when necessary. So far it has covered all my XML/Java-related needs excellently.
i thought xstream could only (de) serialize java beans, how can you map more complicated xml schemas?
I've explored just about every XML parser and package I've come across. Castor has served me very well in the past. JAXB like wise is a solid java-xml-binding driver. For every day use I find XStream does exactly what I need in the simplest and most efficient way. JiBx is also a nice package and I've played with it. Haven't haven't had a chance to use it in a real project, but it is pretty nice.
I agree with Xstream, being that it leaves much smaller foot print compared to others(as long as you have patience and means to update your validations when a XSD falls in the picture)
Just remember that XStream is not used to generate JavaBeans from a DTD or Schema. It is a replacement for binary serialization. Its best features are that the xml that it generates is not verbose, has powerful extra features if you use the Sun JVM, and is small and reasonably quick.
I used it as a way to config a large application and it turned out great. Run the application and you don't get a property map, you get a fully instantiated object graph from the config.
It is fantastic at what it does if you are coming from objects first. If you are coming from a DTD or Schema first then you need another tool like XMLBeans.
I tried with xstream for data binding from java to xml.
if we have any reference in java class, that reference data is not getting populated in xml.Say for an xml i have a person class which in turn contains phonebook class reference.I am setting this person class in another class called company.When i tried to bind the data to xml,that phone number data is not getting populated.
I'd say read the manual/tutorial for more details. Since serializing an entire object hierarchy is the point of xstream I'd be surprised if it just didn't work - especially since I have quite a bit of experience with it.
Is the contained class reference marked transient?
Which mode are you running xstream in? Like I said the JVM-compatible mode is more limited.
Actually, in the jvm-compatible mode the serialization works just like native java-serialization so I guess you could try that to see if your class gets serialized properly.
We experienced another problem (even though it is not considered such), when trying to generate XML from Java objects containing final fields. These fields are not serialized, because it would be impossible to deserialize them if we wanted to.
We, on the contrary, want only to generate an XML representation on a graph of objects, and this information contained in the final fields is important. Unfortunately, I did not find any way to make it available in the XML.
If anyone has an idea...
P.S. : I just took another quick look at the XStream home page, and it says that :
"Serializes internal fields, including private and final."
It did not work for me, the final field was dismissed.
Actually, I missed the FAQ section which details the behaviour of XStream reagarding the JVM.
If you use the Enhanced Mode with a 1.4 VM, the final fields are taken into account ; if not, they are dismissed.
Sorry about the wrong previous comment.
I have been using Castor for a couple years now on my project and that one gets my vote. About a year ago I did a comparison of it and JAXB and found Castor to have a shorter development time to get the mapping logic implemented for our typically use. It also was about 10% faster performance-wise so it was a no-brainer to stick with that.
I haven't tried out XStream or JiBX, but I don't see a reason to switch from Castor at this point.
See the 10.1.3 developer preview link. Straight "ORM" is rather "90's", integrated ORM and OX development tools are where it's at. Integrated caching, locking, transaction integration, etc. JAXB, JCA, Web Services. Etc. Essentially, an "enterprise data services layer".
actually,xstream is by far ,the easiest way to do the job of SERIALIZE java class or complete object graph to xml
then with xstream u have to begin withjava class
in other tools ,u can begin by xml schema and build java classes from it
Maybe I didn't get the concept right: I thought XML binding in Java is that you start with the "schema" (XSD) of the XML, generate Java classes out of it, and then at runtime you can convert the real XML data to Java object back and forth.
In that sense, I used JABX and Castor before. Castor seems more tolerant in that it can be "tweeked" to bind schema that JABX complains to be "invalid". But what puzzles me is that after all this years, why is Castor still 0.9 version?
Looking at this thread, I followed to XStream and Jibx websites. But it seems to me they are not really XML binding tools in that sense that they don't start with the schema/XSD but the real XML data itself. Confused....
I meant JAXB not JABX :)
Maybe I didn't get the concept right: I thought XML binding in Java is that you start with the "schema" (XSD) of the XML, generate Java classes out of it, and then at runtime you can convert the real XML data to Java object back and forth.In that sense, I used JABX and Castor before. Castor seems more tolerant in that it can be "tweeked" to bind schema that JABX complains to be "invalid". But what puzzles me is that after all this years, why is Castor still 0.9 version? Looking at this thread, I followed to XStream and Jibx websites. But it seems to me they are not really XML binding tools in that sense that they don't start with the schema/XSD but the real XML data itself. Confused....wqthttp://jibx.sourceforge.net/xsd2jibx/index.html
It's kind of wierd that nobody mentions Eclipse EMF/XSD. It's the best!
Well if one need a real complex java<->xml binding one'll end up with sax/dom parsers, because one will miss features in any tool. My experience: I was tryied to find a xml that had 3 nesting level and some attributes. I'm lazy and didn want to write java code by myself so I wanted an autogeneration feature from xml. Another reason for that was that xml definition was changed often, so I didnt want to make corrections in many places. The only good autogenaration I found was castor, that need XMLSchema! for that. So this wasnt a good tool for me coz 1. U gotta always update XMLSChema that is complicated task 2. Java autogenerated classes had too complicated structure tu use'em to have a good looking code. So I ended up with DOM parser that simply parsed XML in couple of POJOs - so no flexibility nowadays :(
I think the choice of tool depends on what you are binding. JAXB is the reason why XML<-->Java binding has become such a popular way for Java developers to try and avoid having to learn much about XML, but it can cause as many problems as it solves. From the Sun folk I have talked to, JAXB was really about using XML to do the thing that Java serialisation failed so miserably at - long term serialisation. The underlying idea (as you will all know) is to isolate data that needs to be serialised into data classes that are specially designed for serialisation, and avoid trying to serialise the entire graph of object relationships. If you use XML Schemas as the basis for those serialisation classes, then you know for sure that they are serialisable into XML. So JAXB is a good tool for this problem, the one it was designed to solve.
Another binding problem is how, given some arbitrary Schema, to produce a set of XML classes that correctly represent the data, and can be used to deserialise the XML, manipulate the data, and reserialise the XML. JAXB 1.0 was not so good for this, because it implemented only part of XML Schema. That caused headaches for any standards groups that published XML Schemas, because suddently Java developers were demanding that those Schemas be re-done for work within the straightjacket of JAXB 1.0. JAXB 2.0 is aiming to support all of XML Schema, so this problem may go away. In the meantime, both Castor and C24 IO can handle the Schema for FpML (Financial Products Markup Language, www.fpml.org), which uses a lot of Schema features, so they can probably do a good job with most Schemas. I should add, though, that I am one of C24's power users, and so I've spent more than a bit of time working with them so that it does Schemas the way I need it to. I should also mention that JiBX sounds like an interesting solution in the case where you aren't trying to derive the Schema from the Java, or the Java from the Schema, but just want to get the data back and forth between some XML and some Java classes.
I actually use C24 IO for a different binding problem, where I want to maintain a repository of data definitions that I can assemble into families of related documents/messages. I then want those data definitions to be bound both to XML Schemas and to Java classes, including the necessary marshalling/unmarshalling code. When you get into the question of managing families of Schemas, which share definitions, it is a more complicated problem than if you are dealing with separate and unrelated Schemas. Once you share definitions, it's much easier if you can bind everything to a repository definition somewhere. Having a GUI to speed the creation and management of the data definitions in the repository also helps too.
Dennis Sosnoski's Javapolis presentation
has detailed and relatively balanced coverage of several of the different tools/approaches (JAXB, XMLBeans, Castor, JiBX, etc.).
Serializing/deserializing a known object model into XML (as with XStream, JSX, ASM's XML format, etc.) deserves separate consideration from binding a known XML content model for programmatic manipulation in Java.
I attended the first talk, and I recomment anyone to read the slides and or look at the video when it comes out.
I've used Castor for both databinding and JDO.
It's ok for databinding, but horrible for JDO.
It appears to be an abandoned project, and is way behind other O/R tools such as Hibernate or Toplink.
As well, it doesn't conform to the JDO spec.
Recently I've tried out XStream, and like it much better than Castor.
Ditto here as well. But readers should note: Castor DOES NOT implement ANY JSR. It uses it's own home grown XML and database data binding schemes. It ABOLSUTELY IS NOT A JDO OR JAXB IMPLEMENTATION. After saying that, I'll say that I did not like Castor JDO. We implemented our data tier using Castor and it was nearly disasterous. We used castor in a web application so we were reading an object in one session and updating it in another. Far too often Castor would complain about the the object being updated in another transaction. We've since moved onto Hibernate an never looked back. Hibernate is a much nicer solution and we've not seen and issues like we had with Castor. On the other had, Castor XML is quite nice. Now if only Castor XML and Hibernate could work seamlesly together :)
We've since moved onto Hibernate an never looked back. Hibernate is a much nicer solution and we've not seen and issues like we had with Castor. On the other had, Castor XML is quite nice. Now if only Castor XML and Hibernate could work seamlesly together :)
I've been using JAXB and Hibernate successfully in combination in production situations. Am using Tibco EMS messaging to send xml format msgs. Define the msgs in XSD and use JAXB to generate Java classes for J2EE side (client side is .NET - so use a tool called XSDObjectGen). Use Hibernate to persist unmarshalled Java object graphs.
Only thing used directly out of J2EE is message-driven bean and JNDI (JDBC connections pools indirectly via Hibernate). Use a distributed cache layer to manage state across the J2EE cluster. Do not use entity beans or any session beans (am fiercely anti-rpc).
Has all worked very well so just keep doing the same thing in more and more projects.
JAXB has worked out fine so haven't felt compelled to try anything different.
We've since moved onto Hibernate an never looked back. Hibernate is a much nicer solution and we've not seen and issues like we had with Castor. On the other had, Castor XML is quite nice. Now if only Castor XML and Hibernate could work seamlesly together :)I've been using JAXB and Hibernate successfully in combination in production situations. Am using Tibco EMS messaging to send xml format msgs. Define the msgs in XSD and use JAXB to generate Java classes for J2EE side (client side is .NET - so use a tool called XSDObjectGen). Use Hibernate to persist unmarshalled Java object graphs.Only thing used directly out of J2EE is message-driven bean and JNDI (JDBC connections pools indirectly via Hibernate). Use a distributed cache layer to manage state across the J2EE cluster. Do not use entity beans or any session beans (am fiercely anti-rpc).Has all worked very well so just keep doing the same thing in more and more projects.JAXB has worked out fine so haven't felt compelled to try anything different.
My experience with JAXB is also alright, except that it only supports a "subset" of the W3C schema symantics. So if you use it to bind your own XSD while it's being developed, there'd be no problem since your XSD will always fall in the "subset" that JAXB supports. On the other hand, if you use it to bind XSD provided by someone else (maybe as a service message contract or something), you'd have to count on your luck that the given XSD is within the JAXB subset.
Another up side of JAXB is that the generated Java classes is very OO in the sense that you can use them in your Java code without even a taste that you a dealing with a underlying XML document - They are just Java objects. (In that perspective, so is Castor, but not XMLBeans where you have to sort of start with a "document" in your Java code.) The only "clunky" part is that, with JAXB1.0 all the bound ojbects have to be from a JAXB factory; while with Castor you can do "new" as with any POJO.
The thing with Castor though, is that it's no where near a "standard", and support scope of XSD symatics is very blurry (at least to me :).
ditto, had problems with castor jdo and moved to hibernate instead. its worth pointing out that castor jdo existed long before the jsr and they don't make any attempt to implement the spec.
I was confused when i saw xstream in the list, i've used it on a few projects, but just for (de) serialization. i don't think there is *any* facility in the current implementation to bind arbitary xml formats to java.
I guess if you go by the strict definition of xml-java binding, than XStream doesn't qualify. Looking at it from a functional perspective, it does do many of the same things. XStream doesn't provide a way to compile a schema to java classes. But the beauty of XStream is you can use what ever tool you like to compile schema to POJO's. Atleast in my bias perspective.
LiDO from Xcalia is a data access layer that provides O/R mapping and O/XML mapping within the same product.
It is an efficient, flexible and powerful product fully compliant with the JDO standard.
LiDO XML can be used as a bridge between the IS and Web Services, as an import/export tool or even as a lightweight storage.
It is available since 2 years.
BTW: I fully agree with Don Smith from Toplink, O/R mapping is nice but it is not enough, O/X mapping is as important.
My experiences first and then a question/comment
1 - Used XSLT for view processing - a disaster. Too easy to get very programmatic with XSLT (easy to do if very inexperienced). Doing things with extremely convoluted XSL that should have been done in java. View generation performed VERY poorly.
2 - Custom marshall/unmarshall - excellent performance results, but takes much too long to develop.
3 - betwixt/digester - a good middleground for us so far
4 - JAXB/P - (Ahh my favourite topic) - code bloat !!! (see my questions/comments below
We work with XML middleware extensively, and XML binding is obviously core to our concerns.
However, I lean to strongly typed interface contracts (done only a tiny bit of smalltalk ;-). Our middleware group's current approach is a "let the consumer choose" model. Consequently,we have DTD's that define a huge number of optional entities/attributes. Consequently there is little in the data stream that actually assists the client in the unmarshall process.
This is why(IMHO) we have struggled with code generation approaches (eg JAXB). We end up with a very large number of redundant classes, because while the DTD provides a very loose interface contract, the reality is that for a certain "request id" a specific subset of the XML is actually delivered. We have had circumstances where less than 10% of the attributes are actually utlised in the message.
Should I be worried about this "code bloat" with our current usage scenario or just let the "complexity hiding" of the code generation approach do its thing and we "get on with it". (personally I am uncomfortable with this)
Also, have a look at the SDO stuff in the latest WAS Tech Journal - the XML binding looks really cool (perhaps C24 SDO - happy to collaborate on that one !!!!)
Here's another $0.02...
I can only comment on 3 of the tools mentioned here (JAXB, Castor and XMLBeans) but of those three I'd give two thumbs up to XMLBeans. I'd previously used Castor pretty extensively, but finally started hitting limitations with its schema support. At the time I reviewed JAXB (beta) it had even poorer support than Castor (ie. some schemas Castor could handle JAXB bauked at). XMLBeans on the other hand hasn't had a single issue with any of the schema I've thrown at it thus far.
Note that I don't have any "fancy" requirements though: I have a set of (reasonably static) XML schemas and all of the XML I'm dealing with conforms to one of those schemas. I have no idea if it's suitable in a more dynamic environment (ie. where you need to generate and possibly update your bindings at runtime).
I am little surprised to see that no one has posted the comments for XMLBeans. I have tried it recenlty, and it seems to work really good. It has 100% support for XSD and generates the objects that can be used without any further modifications. Since it has been donated to Apache, it is open-source now and should work with any application server.
We tried it. We ended up with a domain model that now has approx 500 meaningless java classes and interfaces plus our compile time increased 3 fold. Wouldn't recommend it for situations with really complex XSD schemas.
re: XMLBeans, here's a blog post and sample illustrating XMLBeans and .NET interop: http://blogs.msdn.com/dotnetinterop/archive/2005/02/11/371035.aspx
What about webMethods GLUE - isn't it still available with a pretty liberal license? I found GLUE to have a simple, effective model. Much simpler and quicker to compile than XMLBeans.
What about webMethods GLUE - isn't it still available with a pretty liberal license?
FWIW - I've spoken to several customers that won't touch GLUE because the license is a nightmare. I've never read it personally, but apparently the license was written by an engineer, not a lawyer, whatever that means ..
Cameron PurdyTangosol, Inc.Coherence
: Shared Memories for J2EE Clusters
From performance perspective I was wondering which scheme would work good? In my project we are using JAXB and I am not too terribly happy with JAXB especially when unmarshalling large documents? Is there some kind of document out there that does a comparitive study of all these Java<->XML<->Java transformation?
Am I the only person here who is looking for a tool to go from Java to XML? All of these tools, in my experience, are great for people who have an XML Schema or dtd and want to have horrible generated classes created by the tool. I'm looking for something more like a Hibernate, but for XML. I have a well-defined Java API and would like to have something that makes XML serialization of that API easy to handle. I want to have control over the serialization, so only what I want serialized gets serialized, and so that the result in XML looks how I want it to. I want to be able to go back and forth from Java to XML, with my Java classes describing the "schema", not XML. I also want to do it declaritively, so my Java classes don 't get polluted with XML-serialization-specific artifacts, interfaces, or semantics, and so I can create the serialization definitions I need with legacy APIs as well.
This seems like a pretty useful way of looking at XML binding, but no one I've seen (of the tools I've mentioned) seems to think of things this way. Everyone seems drunk on the power of XML Schema and XSD, which I got burned on years ago. Am I missing something in the tools mentioned? I would love it if I were.....
Drew, it sounds like XStream is a good fit for this. I don't know if it has control for only serializing part of an object, but based on the positive comments here and a quick glimpse of the javadocs and tutorial, it looks very simple and the Converter interface seemingly provides plenty of flexibility.
I think those of us that do need to deal with an XSD don't necessarily do so by choice - it's just sometimes what you're dealt. We have 70 XSD's from a data provider that we need to unmarshal, and Castor has performed fairly admirably for us. We had some problems with its xsi:nil support, which led us to XmlBeans. We may have done something wrong with XmlBeans - the code we generated did not have an empty constructor, which proved to be a problem since we want to shove some of the objects into the database with Hibernate. Anyone know if it's always the case that there's no empty constructor for XmlBeans-generated classes? Again, I may have missed an option, and we went back to Castor since it was working well enough.
My two cents regarding Castor is it seems like they should drop the JDO support and concentrate on the XML binding framework, since what they have is fairly powerful and usually fits the bill when an XSD-to-Java framework is needed.
Drew, it sounds like XStream is a good fit for this. I don't know if it has control for only serializing part of an object, but based on the positive comments here and a quick glimpse of the javadocs and tutorial, it looks very simple and the Converter interface seemingly provides plenty of flexibility.I think those of us that do need to deal with an XSD don't necessarily do so by choice - it's just sometimes what you're dealt. We have 70 XSD's from a data provider that we need to unmarshal, and Castor has performed fairly admirably for us. We had some problems with its xsi:nil support, which led us to XmlBeans. We may have done something wrong with XmlBeans - the code we generated did not have an empty constructor, which proved to be a problem since we want to shove some of the objects into the database with Hibernate. Anyone know if it's always the case that there's no empty constructor for XmlBeans-generated classes? Again, I may have missed an option, and we went back to Castor since it was working well enough. My two cents regarding Castor is it seems like they should drop the JDO support and concentrate on the XML binding framework, since what they have is fairly powerful and usually fits the bill when an XSD-to-Java framework is needed.
First of all, I don't think "Java -> XSD" is "binding" by definition - If I am not mistaken, "binding" means "XSD -> Java"; and only at runtime "XML <-> Java" can happen both ways.
As per empty constructors with XMLBeans bound JavaBeans, I guess they may have that way by design - just as in JAXB you can't do "new" to get a bound bean instance, looks like you can't do that with XMLBeans, either. Bean instances come from factory not constructors. Can someone in the "know" confirm/correct this? Thanks!
I think you need to look at why you're using XML in the first place. If you need a standard data format that can be passed between disparate systems (Java or not), you should have an XSD that defines that format. Without it, there's no way to validate the data that's being passed. When I encounter customers that are using XML as a data transfer format, I generally recommend that they define XSDs, regardless of the XML binding technology they're using.
I've found XMLBeans to be a very productive way to work with XML whenever XSDs are involved. I tried Castor a couple of years ago, and, while it was a decent first-generation binding technology, it seems to try do to too much (XML + JDO), without showing much leadership on the standards front. With the growing number of XSD tools available for automatic document creation and rules management, it's more important than ever that you data binding tools support the formats and rules being defined.
Also, XMLBeans is much more aligned with JAXB than Castor, and hopefully, with Apache's support, will be JAXB compliant in the next iteration (or JAXB will be XMLBeans compliant, depending out your perspective). One of the things I'm waiting for in the next version of XMLBeans is portable XQuery/XPath support. Looks like the XMLBeans team is also researching support for starting with POJOs, which would allow XMLBeans to handle additional use cases.
To me, the primary use case for XStream is serialization of Java Objects for subsequent deserialization. This can be very useful when the business logic within classes change frequently, but the data the classes manage changes less so. With XStream, I can persist class information for longer periods via XML Serialization and still reconstruct my classes as my application requires, even if I've added new methods to the class. XStream is ideal in this case because typically, a Java Class is more logic than data oriented (that is, the XML will be relatively small), and the serialization is frequently less of a performance issue than the actual persistence (DB or file). I would be curious to see preformance information for large XML files, repetitive XML processing, or XML changes.
PS: To answer the questions posed about creating new XML documents, they are created like in JAXB, via Factories, like: myXmlDocument.Factory.newInstance().
I have read that most of the XML binding frameworks generate Java classes to hold data. I assume that these classes are tightly coupled with the XML binding framework used eg.XMLBeans, JAXMe.
I have read that Castor allows us to use our custom VO's for XMLBinding instead of using the generated classes.
Are there other frameworks which can be used to do this?
The problem with XML <-> Java binding tools is that when starting from either side, on the other side you are getting XML'ish (XSD'ish) Java code, or Java'ish XML. Then you go into tweaking the binding definitions, but, if the mapping is not trivial (which is often the case), it gets complex pretty fast.
IMO, the real problem is not as much Java/XML impedance mismatch (both are type-based models), but rather the fact that there is often an implied transformation layer between XML structure you want to expose to the outside world and your internal Java object model. Indeed, a well-designed XML schema is primarily concerned with constraining the data, while a well-designed Java model is all about encapsulating behavior.
Thus, when starting with the schema, the generated Java classes are often treated as a kind of DTO that still needs to be post-processed to be mapped to the "real" object model. However writing the mapping code in Java is tedious, and it tends to be hard to adjust to schema changes.
The solution that worked for me was using XStream in combination with XSLT: XStream makes Java/XML marshalling/unmarshalling a trivial task, while XSLT is a powerfull language for "binding" between XStream-generated XML and the target XML. And it is pretty fast too as you can use SAX between XSLT transformer and XStream reader/writer. I think this approach is close to the ideology behind JiBX (which I have not worked with), but I suspect that JiBX binding specs are not as powerful as XSLT can be...
I have admittedly never used Castor for generating XML, for all I know that part of Castor may work flawlessly, I do however have my doubt's. After looking under the hood of castor a few years ago I found RDBMS mapping implementation to be VERY shaky at best (I doubt much has happened since, project was semi dead by then allready). I suspect implementation of XML part may not be much better.
JAXB: "...and of course no DB support (you have to use Entity beans or jdo etc if u need it)"
Check out my HyperJAXB project (http://hyperjaxb.dev.java.net
) which provides Hibernate-based DB support for JAXB-generated classes.
I have been using EXML (Electric XML) from TheMindElectric. They have since been bought by web methods and the EXML is part of the webMethods GLUE web service framework. Don't know if that is still free like it was at the time I found it a few years back. I totaly screams as a parser and Java binding. I also handles SOAP serializations. http://www.webmethods.com/
I tryed using only few of the xml-binding tools you spoken about. I think that hibernate, toplink or other orm, arent't exactlty xml-binding tools, almost in their main porpouse, so i'm not talking about them. I played with JAXB & Castor and before trying xgen (included in the docsoap suite (try http://www.textscience.com/papers/DocSOAP_XDK.html
)) my favourite tool was Castor even if it had many schema mapping limitations. Even if i don't know if it's completely free i think xgen is the best binding tools i ever used. Generated classes are very close to the xml-schema and performance of them(marhalling-unmarshalling) are very good. The only drawback i found is related to the very expensive memory usage during the generation of schema classes: parsing a 60kb schema (comments excluded) may require lauching the vm with the -Xmx512m or the -Xmx256m option. However not a real problem, in my opinion.
Giovanni De Facci
How do you guys think about APACHE Betwixt ?
It's a new one, and the lastest version is 0.6
We can parse xml to beans with digester, and write the beans to xml using Betwixt.
JONAS and struts use it, and it's jakarta commons tool.
It's lovely. :)
I wrote a framework called Java XML Mapping (JXM), because I wanted a way to specify the binding in Java code rather than an XML binding document. The code is available at http://jxm.sourceforge.net
. It supports default serialization deserialization for classes using Java Beans naming conventions, and you can register custom serializers. It is fairly simple, but has met my own needs.
Another group has extended JXM in a framework called "Beck" at http://beck.sourceforge.net/
I use XMLBeans for 1 year, and it meets all my expectations.
Actually, JAXB was my first binding experience. At this time I had no time to compare the different solutions and my xml schema was simple. So I trusted the J2EE specification.
Few weeks later my schema repository has grown to 40 schemas files with severals namespace including the FpML schemas quoted by John Davies. JAXB has never succeeded in generating the java source files... I reached the JAXB limits.
Moreover I was fed up with the redundant and verbose code required to build a JAXB object.
So I took time to compare the main binding solutions : Castor, XMLBeans, Jaxme,... The IBM benchmarks were very instructive.
The BEA signature, the Apache Foundation, and the full W3C compliance with W3C convinced me to use XMLBeans. (The Maven plugin was an argument too)
Today I am completely satisfied of XMLBeans. Classes are generated easily. My source code is clear and brief. Content access is staightforward and rich (xml indice, getter etc.)
Note; the migration from JAXB to XMLBeans was very easy because the naming convention are the same.
We had to write a client to document-based web services a while ago and as a result had to convert java objects to and wrap that in SOAP. We found XStream very easy to use, but unfortunately there was a bug in the JRockit JVM (BEA's) and we sadly had to abandon XStream for Betwixt. Betwixt is alright as well, but I'm an XStream fan.
Try ActiveXML for a binding tool @ http://www.activexml.org
The Maintenace Release 3 will be out first week of January and would have quite impecable features to it. (Swing GUI support for example, binary format mappers, serializers and more out-of-the box XML bound Java components)
Do not mean this as the ad of any sort, but since we are talking about the XML binding tools, here is one to consider, not hiding that it is being developed by me under the xDev Group.ORG logo.
Artem D. Yegorovhttp://www.activexml.org
I used java 1.4s XMLEncoder/decoder plus 2 XSLT files that define in and out mappings between java model and fixed XML schema.
Works great for what i need.
My vote for XMLBeans.
I've been using XML to Java to XML "binding" for some time. My experience with Castor has been very positive -- however I have had more success with their XML framework than their JDO mapping. We have used Castor in multiple production systems as an XML binding framework and have found it to perform very well. It also does a good job with most XML Schemas, although more flexibility with respect to Java packages would help with some XML Schemas. That said, Castor does have some limitations: to my knowledge XMLBeans is the only xml binding framework that preserves the whole XML infoset (processing instructions, comments, etc.) which is important if the XML document is one that might be edited "by hand".
Ronald Bourret maintains a list of XML data binding
How do you perform java <-> xml binding (marshalling and unmarshalling)?
There's new support for the Java Architecture for XML Binding (JAXB
) in the Stylus Studio XML Schema Editor
The Stylus Studio Team
About Stylus Studio: Stylus Studio is the industry's most innovative XML IDE
providing advanced support for XML and its related technologies: XSL, XSLT
, XML Schema
, SOAP, WSDL, EDI
, SQL/XML, XML Mapping
, Web services
, Legacy data integration
. Used by leading software developers world-wide, Stylus Studio simplifies XML programming and enhances developer productivity
through innovation. Visit the Stylus Studio
Web site to learn more, or download
a free trial today.
The Eclipse Modeling Framework, EMF
, provides a wide range of solutions to this problem. Following the simple on-line tutorial
will help you understand what it does. I recently presented at EclipseCon on the topic of XML binding
and have provided a detailed example
illustrating how this all works.
EMF provides some very interesting capabilities not supported by the other technologies, such as the ability to process a strongly typed dynamic instance without generating any code. I.e., given just a schema, EMF can process XML instances on the fly without the need to generate code, while still providing all the type safety of generated code. The example project above shows this in action. In fact, it even shows how to create a schema document dynamically using the XSD
With the recently added support for round tripping Ecore
-> XML Schema
-> Ecore, it's even possible to define operations (methods) directly in your complex types, including the Java code for each operation body. In other words, EMF helps turn XML Schema into a full blown modeling language that's almost as capable and expressive as UML. And if you don't like the code that EMF generates, you can even change the templates to generate what you really want. Once you have a model, the possibilities are endless...
Clearly EMF's focus is much broader than just the XML binding problem, so it's easy to overlook it when focusing only on pure XML binding technologies. But I think that would be a shame, because I'm sure that XML is not the be all and end all in the drive toward improved data integration.
All the tools mentioned so far seem to require some form of compile time code generation. Is there anyway of doing Java XML binding dynamically through the use of a mapping/binding file? This would be similar to the way that Hibernate does ORM. Simply supply the mapping file, bounce the system and it can automatically handle the new XML schema and map it to your object model or vice versa?