Bindmark is a java.net project that compares the time and memory performance of Beck, C24, Castor, Glue, Javolution, JAXB, JAXB 2.0, JiBX, JSX, JXM, Liquid, Skaringa, XMLBeans, XStream and Zeus in regards to XML-Java binding.

Checkout bindmark here:
http://bindmark.dev.java.net/current-results.html

http://www.eod.com/devil/archive/xml.html

...and embrace PL :P

http://alt.textdrive.com/pl/

http://www.eod.com/devil/archive/xml.html...and embrace PL :Phttp://alt.textdrive.com/pl/

OK, what's the advantage here? I really have never understood why some people hate XML so much.

I really have never understood why some people hate XML so much.

Hate? Despise would be more appropriate.

To paraphrase someone, I really have never understood why some people love XML so much.

Interesting that terms like hate or love are used towards different technologies...

Aren't you supposed to be non-biased as far as one technology over the other goes and develop solutions based on which technology fits best the task at hand, not which technology you "love". Otherwise it would be very unprofessional and extremely unproductive.

 

Hate? Despise would be more appropriate.

Shouldn't you despise yourself for not understanding applicability of a given technology to certain solutions, rather than despise a technology for not wiping your nose and doing tricks for you? Sounds childish to despise something that seems like you do not understand as you have not provided a logical reason for your trolling arguments...

Do not take this personal, just reason and your arguments might just become that much sound.

Sincerely,

Artem D. Yegorov
http://www.activexml.org

Shouldn't you despise yourself for not understanding applicability of a given technology to certain solutions, rather than despise a technology for not wiping your nose and doing tricks for you? Sounds childish to despise something that seems like you do not understand as you have not provided a logical reason for your trolling arguments...

Suddenly... I realized that... you are absolutely right. I must confess that I have a very low self-esteem indeed.

Thanks for your help! Much appreciated! I already feel much better thanks to your many incisive insights :)

Interesting that terms like hate or love are used towards different technologies...Aren't you supposed to be non-biased as far as one technology over the other goes and develop solutions based on which technology fits best the task at hand, not which technology you "love".

Lack of passion is sure sign of easily manipulated careless drone.

2 c observation.

Lack of analysis is far worse, since nowhere do I talk about lack of passion, in this case I am talking about idealism which leads you nowhere in developing solutions. You can still be passioante about process of integrating different technologies and finding a technology that fits a given solution, not passionate about which technologie's dick is bigger, as such is not passion but a mere childish ignorance.

Words like hate or love do nothing in the world of precise sciences, but a logical argument does and such can be passionate in itself, mere emotions are a good sign of an ignorant dolt.

Sincerely,

Artem D. Yegorov
http://www.activexml.org

Artem, don't be so emotional.

...and denounce my cultural roots? Only if I drink enough Vodka...:-) No emotions, though a great way to get this morning stress out of the way before diving back into the rest of the day problems...

I hate XML.
Being non-biased != having no attitude.
I loved it on the beginning, when its purpose was meaningfull. Now, after it went through "marketing mill" it is just a salad of acronyms and misconceptions, with absolutely no substance. Destined to slowly fade away.
And, regarding its applicability... Well, you know that stuff about hammer and nails...

I hate XML.Being non-biased != having no attitude.I loved it on the beginning, when its purpose was meaningfull. Now, after it went through "marketing mill" it is just a salad of acronyms and misconceptions, with absolutely no substance.

Strange, I thought the XML was still XML. Why would the usefulness of it suddenly diminish because of "marketing exploitation"? If you wanted to use XML before I don't see why you wouldn't want to use it now - it should still do the same job for you?

I like XML for some things, but I don't see it as the next saviour coming to redeem us from all evil. Perhaps then I'm not "passionate" and just a "drone" (as per Konstantin's statement above), and have no attitude. But hey, if being flexible is being a drone then I guess I have to live with it.

yeah i guess your attitude when you end up staying late in
the evening is really going to be shaped by whether or not
you have a vested interest in the relevant buzzword du jour.

--b

yeah i guess your attitude when you end up staying late in the evening is really going to be shaped by whether or notyou have a vested interest in the relevant buzzword du jour.--b

Unless 'du jour' means "over the last several years" (at least) I don't see how XML is a 'buzzword du jour'.

Unless 'du jour' means "over the last several years" (at least) I don't see how XML is a 'buzzword du jour'.

Actually, 'du jour' is a kind of soup, and it's one of my favorites ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Actually, 'du jour' is a kind of soup, and it's one of my favorites ;-)

I almost replied to explain what 'du jour' actually means. Must... drink... more... coffee.

I read the review with interest but feel compelled to respond to some of the criticism leveled at C24 IO.

First of all IO is a meta data repository. It comes with pre built models for many financial standards such as SWIFT, CREST, Fedwire, Oasys Global etc. In fact it is a generic data modeling (and transformation) toolkit which can interact with XML schema, DTD, RDBMS, RELAX NG, XMI, HTML, flat files, etc.

It comes with a GUI for editing and transforming these data structures and it's code deployment and meta data import features can all be accessed via ANT tasks. The code IO produces can be fully customized, down to package names, class suffixes, custom serialization, bean classes and a whole lot more.

Granted IO may be slightly slower than some other technologies around but it can round trip every XML schema construct. Schema's such as FpML 4.2 which are know to crash XML Spy (SP1) work fine - I for one would be interested in seeing this test rerun against a more complex schema, with all the intricacies of substitution groups, redefines, identity constraints etc. IO also extends XML schema by adding the ability to code your own validation rules (in XPath or Java) - in fact it comes packaged with the pre built rules for the FpML schema - something which very few other tools can boast.

IO is free for non commercial use, but given the excellent support and an enormous amount of extra functionality than just being a Java / XML binding framework, we believe it is worth paying for.

And with version 3.1 soon to hit the shelves it's worth checking in on.

IO is currently being used in many of the largest banks, clearing houses and other financial institutions around the world. So if you're looking for something to embed in your app which can parse the occasional simple XML messages then use JAXB 2.0, but if you've got money to spend on professional integration technogy then take a look at IO.

Simon Heinrich
Product Development Manager
C24

I have to agree with Simon.

More over, not all the binding frameworks compared are in the same "class". Something like C24 is a behemoth which exists for a TOTALLY different reason than XStream(which I love and use by the way).

This is like testing ALL types of cars and saying a mini is smaller and more economical than a ferrari.

It would be great if the study categorized the frameworks and compared them in each category. (Like Sports cars, Luruxy cars, economy cars etc)

I totally agree with Simon's view. We integrate both XStream and C24 IO for 2 different purposes.
As a light-weight mechanism, XStream is ideal for loading XML configuration files and I would never think about using C24 IO for this purpose.
On the other hand, the C24 libraries help us to interface with some very complex XML and non-XML standards in the financial industry. We switched to C24 IO from another product due to the ease of use for that level of complexity.
Marc Binck
Chief Technology Officer
AB Prodata

I agree that the way the BindMark results are presented is unfair to many of the products in the comparision. If you do a benchmark based only the the limited functionality that JAXB has, you are likely to find that JAXB is the best at doing it. Wow, what a surprise ... It worried me though seeing comments about IO's GUI being 'unintuitive'. Most UIs are unintuitive unless you have used something similar in the past. These kinds of comments aren't helpful when they only come from one person.

We have finally got hold of the bindmark source code and found that the allegged "OutOfMemoryError after about 6000 unmarshals" is NOTHING TO DO WITH C24. It is thrown because new Log4J appenders are added to the Log4J system on every iteration. Simply moving this code into the constructor resolves the issue.

We have also noticed massive inconsistencies in the unmarshaller classes. In some (such as C24) the unmarshalling framework is recreated on each iteration (which includes recreating a SAXParser), but in others the same objects are reused. This makes a MASSIVE difference to the results and when this is fixed and the tests rerun I would expect IO to be placed close to the top of the list.

... so let's not all believe everything on face value!

Simon Heinrich
Product Development Manager
C24

xStream in my opinion is the easiest to implement.

Jeff

Is it just me or is Binding XML to Java not all that useful.

Basically its taking a flexible data format and hadcoding references to element paths all through your code?

I work with this one standard XML format where there are many levels of elements with nothing but a single element below it (don't ask me why.) We ended up with pages and pages of this in JAXB:

if (parent != null) {
   Child child = parent.getChild();

   if (child != null) {
       GrandChild grandChild = child.getGrandchild();

       //etc...
   }
}

And pray the XML schema doesn't change. That's a refactoring nightmare. I hate DOM too but at least I can write a method that will dig down without hardcoding paths or null checks. I just think these tools don't really provide a lot of value in the long run.

Binding to custom class types is another thing altogether.

I've used JAXB and have had a generally good experience with it. Why wouldn't you think binding is useful? Perhaps you're not using it effectively, or you really don't have a use for it.

I worked on a project that involved data from a database that needed to be converted to XML and transformed via XSLT. I designed the XML schema, ran JAXB's XJC task in ant, and in mere seconds I have an object representation (which are more or less POJOs) of my .xsd.

The POJO is easy to use and can easily be integrated into your architecture, i.e.

DB <-> DAO <-> POJO

You'd probably want to make a 'wrapper' for your POJO to simplify it's instantiation (i.e. new Thing() as opposed to going through the ObjectFactory).

My gripes with JAXB? I haven't looked into any of the other frameworks, but one annoying thing about JAXB is that if you have an attribute in an element (i.e. <myelement someattr="someattrval" />), JAXB makes inner classes for that attribute that you also have to create through the object factory. Just a minor annoyance. Otherwise, it's awesome being able to marshal and unmarshal XML to Java via JAXB :)

DB <-> DAO <-> POJO

I see this as an example of the domain aenemic domain model pattern. I'd bet a dime those POJOS don't have any behavior. When I've had a rich domain model, I've found it easier to use XPath to extract data from the XML and build my domain objects how I wanted. Any binding that gives you generated POJOS will still require translation to (real) domain objects. XStream works well too, but I found XPath with dom4j simpler and more direct.

Your mileage may vary, but I like to keep XML and any other transport technology/pattern at the edges of my apps whenever I can.

I've used JAXB and have had a generally good experience with it. Why wouldn't you think binding is useful? Perhaps you're not using it effectively, or you really don't have a use for it.

I think effective binding would be a tool that lets you bind XML to custom types which is, in theory what tools like JAXB claim to be able to do in addition to creating classes for you. However, if found the reality was much different from theory. I haven't seen a tool that really makes custom binding powerful and elegant. If you or anyone else knows of one, please point me towards it.

I don't think creating a set of classes to mirror the structue of an XML document is very effective. It just couples your system to the schema. That's a huge step backward as far as I am concerned. For example, adding an optional element to a schema in one part of a system requires regenerating the entire set of JAXB classes and updating them system wide regardless of whether that change affects anything else.

Fundamental changes to the structure of a schema mean large scale refactoring to everything that references the JAXB Objects. Using an dynamic binding tool, and a custom wrapper or factory, you can merely update the paths and have mulitple schemas map to the same Object hierarchy.

I worked on a project that involved data from a database that needed to be converted to XML and transformed via XSLT. I designed the XML schema, ran JAXB's XJC task in ant, and in mere seconds I have an object representation (which are more or less POJOs) of my .xsd. The POJO is easy to use and can easily be integrated into your architecture, i.e.DB <-> DAO <-> POJOYou'd probably want to make a 'wrapper' for your POJO to simplify it's instantiation (i.e. new Thing() as opposed to going through the ObjectFactory).

As others have mentioned and I am trying to demonstrate, this is brittle. If your system is largely static over time it's fine but for a living and changing application, it's a maintenance headache.

My gripes with JAXB? I haven't looked into any of the other frameworks, but one annoying thing about JAXB is that if you have an attribute in an element (i.e. <myelement someattr="someattrval" />), JAXB makes inner classes for that attribute that you also have to create through the object factory. Just a minor annoyance. Otherwise, it's awesome being able to marshal and unmarshal XML to Java via JAXB :)

I had to fix a JAXB-coupled class written by some contractors who apparently didn't understand what causes NullPointerExceptions. I ended up with literally over a hundred null checks in that single class to build an Object with about 30 data elements.

A big problem with binding is that people bind because they have binding tools, not because they should bind. Actually, I see Java/C# developers using binding tools (aka Schema compilers) because they don't want to have to understand XML and Schemas, and these tools hide it from them.

The thing is, XML is commonly used as a decoupling mechanism for systems that have to communicate. If you tightly couple to your decoupling mechanism, then you have to either create a different decoupling mechanism, or you end up with a brittle coupling between your systems.

The only way to cope with version change in systems and message/document specs is to have a layer somewhere which is responsible for mapping the outside world to your applications inner data model, so that changes are confined to that layer and don't knock on throughout your entire data model.

It's a lesson that many groups don't seem to have learned yet.

Cheers, Tony.

A big problem with binding is that people bind because they have binding tools, not because they should bind. Actually, I see Java/C# developers using binding tools (aka Schema compilers) because they don't want to have to understand XML and Schemas, and these tools hide it from them.

Yes.

The thing is, XML is commonly used as a decoupling mechanism for systems that have to communicate. If you tightly couple to your decoupling mechanism, then you have to either create a different decoupling mechanism, or you end up with a brittle coupling between your systems.

Exactly. Couldn't have said it better.

The only way to cope with version change in systems and message/document specs is to have a layer somewhere which is responsible for mapping the outside world to your applications inner data model, so that changes are confined to that layer and don't knock on throughout your entire data model.It's a lesson that many groups don't seem to have learned yet.Cheers, Tony.

Thank you. 'Binding' is actually such a good word for this because that's where your code ends up: bound to the schema.

all good points. the sad thing is the industry is heading forwarding with schema this, schema that. Having read over the schema spec a few times and tried to understand all the parts of schema, there are something in schema that just don't make any sense.

for example, in schema, it's valid to have this:

<choice>
  <sequence>
     <choice>
      .... repeat until you get dizzy/sick
     </choice>
  </sequence>
</choice>

Schema should limit it so that a choice may nest a sequence, but the subsequent sequence may not nest additional choice elements. There are other annoying things about schema, but I'll stop there.

peter

Actually, the problem isn't that Schema datatypes can have arbitrarily deep structure using sequences and choices, the problem is that most programming languages don't have anything equivalent to map that structure on to. The thing is, naming is still the hardest problem in IT. What XML folks realised is that there is often no need to have to name every node in structure uniquely, as long as you have some way to access those nodes (which is what XPath gives you).

When you map these structures onto Java, C#, etc., you end up having to create a Java class for each embedded sequence/choice in your XML type. Since they don't have to have names in the XML, the names have to be created programmatically, which means they will just be bad names. I have sometimes changes Schemas to limit the depth so that I don't end up with auto-generated class names, but that is me being forced into a design decision by a binding tool, and that isn't the way it should be.

It would be way cool if you could implement sequences within choices, etc., using some kind of anonymous class technique that saved you having to find names for those classes. Combine that with some kind of "JPath" functionality for accessing values in those anonymous class trees, and you would have something that would be very useful even when not using XML, once people got their heads around it.

I'll say it again, naming is still the hardest problem in IT. XML tools have found a way to help reduce the amount of naming you have to do. When are Java, etc., going to step up to the plate and problem the same kind of help to us?

Cheers, Tony.

Typo!

When are Java, etc., going to step up to the plate and *provide* the same kind of help to us?

all good points. for now I'll settle for something slightly easier to compile into classes.

Spring rocks !

A big problem with binding is that people bind because they have binding tools, not because they should bind. Actually, I see Java/C# developers using binding tools (aka Schema compilers) because they don't want to have to understand XML and Schemas, and these tools hide it from them.

Depending on their role in the organization, this is not necessarily a bad thing. There is nothing wrong with using a tool that facilitates the reading/writing of XML and makes it as painless as practical. If the goal is simply to serialize some XML into and out of the system, particularly if the schemas are already defined by someone else, then abstracting away the minutae and detail that isn't necessarily relevant to the actual serialization problem is not a bad thing.

The thing is, XML is commonly used as a decoupling mechanism for systems that have to communicate. If you tightly couple to your decoupling mechanism, then you have to either create a different decoupling mechanism, or you end up with a brittle coupling between your systems.The only way to cope with version change in systems and message/document specs is to have a layer somewhere which is responsible for mapping the outside world to your applications inner data model, so that changes are confined to that layer and don't knock on throughout your entire data model.

There is nothing that says that the classes that are generated and used by these tools have to have a 1-1 corellation with anything within your domain model. They can simply be a mechanism, implemented AS classes because of the nature of the Java environment, that makes transfer from the domain model to XML simple to do and easy to implement.

Just like DTO's for SQL databases.

As a Java developer it's a heck of a lot easier to use and understand:

XMLObj x = getXMLObjFromStream(stream);
DomainObj d = new DomainObj();
d.setProperty1(x.getProperty());
etc.

This hides the actual XML part and the Java coder can focus on the translation of the "raw" XML Object to Domain Object, and they can do this with essentially zero XML knowledge because at this level, the fact that it's XML is a detail.

There is nothing that says that the classes that are generated and used by these tools have to have a 1-1 corellation with anything within your domain model. They can simply be a mechanism, implemented AS classes because of the nature of the Java environment, that makes transfer from the domain model to XML simple to do and easy to implement.Just like DTO's for SQL databases.As a Java developer it's a heck of a lot easier to use and understand

No one is arguing that they aren't easier to use faster to implement. The problem is that as a mechanism for working with XML, creating an Java Object model based on a particular schema is an exceedingly poor one in the long run. Just because you can take something that you don't understand and convert it to something you do understand doesn't mean that you should.

Binding your Object model to a schema is like locking fire exists at a club. It's easier and cheaper than posting guards at the doors but if there's a fire it starts looking more like a bad choice.

I work with old code that is bound to a schema and the cost of maintaining that code is extremely high in comparison to a more complex DOM or SAX based solution.

So far I have been using JDOM for parsing XML and as you said, it's encapsulated in one class. But once the file is parsed, you have to do something with the data - create objects, set values etc.

I have decided to take a look at XML Binding the next time I have to do this. I don't see that encapsulation has to break at all. If I generate a jar file with JAXB, I can still use the "Parser" class to fetch data from the objects and do what it was doing earlier (creating objects, setting values). What I have saved is writing the parser code and having to keep updating it when the schema changes. Now when the schema changes, I just regenerate the jar file.

Regards
Milind

I have decided to take a look at XML Binding the next time I have to do this. I don't see that encapsulation has to break at all. If I generate a jar file with JAXB, I can still use the "Parser" class to fetch data from the objects and do what it was doing earlier (creating objects, setting values). What I have saved is writing the parser code and having to keep updating it when the schema changes. Now when the schema changes, I just regenerate the jar file.RegardsMilind

No, you have to rewrite the parser because it will no longer compile. Also, you mght find that you end up with more (and more redundant code) to create your 'parser' that reads from JAXB.

When I use DOM, I generally use a utility method that takes a '/' separated relative path and a node. If the schema changes, it's normally a matter of changing these paths.

With JAXB, there is no way to do this unless you tell JAXB to give you an element as a DOM node (defeats the point of using JAXB.) You must* hardcode evey path in the parser. Not only that, my utility method will not throw a NPE if an element doesn't exist. I can have it return null or creae defaults or switches to create different behaviors. Wthi JAXB, you have one option. check (element != null) before trying to do anything with the element. More code more errors. More time wasted. It's a bogus strategy. I've done it both ways nd I know that the JAXB way is inferior.

I have decided to take a look at XML Binding the next time I have to do this. I don't see that encapsulation has to break at all. If I generate a jar file with JAXB, I can still use the "Parser" class to fetch data from the objects and do what it was doing earlier (creating objects, setting values). What I have saved is writing the parser code and having to keep updating it when the schema changes. Now when the schema changes, I just regenerate the jar file.RegardsMilind

No, you have to rewrite the parser because it will no longer compile. Also, you mght find that you end up with more (and more redundant code) to create your 'parser' that reads from JAXB.When I use DOM, I generally use a utility method that takes a '/' separated relative path and a node. If the schema changes, it's normally a matter of changing these paths.With JAXB, there is no way to do this unless you tell JAXB to give you an element as a DOM node (defeats the point of using JAXB.) You must* hardcode evey path in the parser. Not only that, my utility method will not throw a NPE if an element doesn't exist. I can have it return null or creae defaults or switches to create different behaviors. Wthi JAXB, you have one option. check (element != null) before trying to do anything with the element. More code more errors. More time wasted. It's a bogus strategy. I've done it both ways nd I know that the JAXB way is inferior.

in the case of castor, there's an option to ignore extra attributes and elements, so additions to a schema need not break an application. missing elements on the otherhand, will still throw exceptions in castor, so in a "unreliable" situation, I'd totally agree a mapping approach is more flexible. though, I think the approach JiBX uses may provide similar level of flexiblity to mapping approach, while still using binding techniques. just some random thoughts. I've also used both approaches and both have their strengths and weaknesses.

If I remember correctly, JAXB started way back in 2000/2001 and stalled for over a year. I think the original RI took a different approach. When JAXB work started up again, they went with the current approach. My memory is foggy, so I could be wrong.

peter

in the case of castor, there's an option to ignore extra attributes and elements, so additions to a schema need not break an application. missing elements on the otherhand, will still throw exceptions in castor, so in a "unreliable" situation, I'd totally agree a mapping approach is more flexible. though, I think the approach JiBX uses may provide similar level of flexiblity to mapping approach, while still using binding techniques. just some random thoughts. I've also used both approaches and both have their strengths and weaknesses.If I remember correctly, JAXB started way back in 2000/2001 and stalled for over a year. I think the original RI took a different approach. When JAXB work started up again, they went with the current approach. My memory is foggy, so I could be wrong.peter

Caveat: I'm only familiar with the first version of JAXB.

My problem is not with tools that allow you to bind XML to custom Object heirarchies. I think that is a really effective strategy, if you can pull it off.

My problem is with generating classes that match the XML schema. This is an asinine apporach, IMO, becuse desinging a schema and designing Java class relationships are two very different things.

in the case of castor, there's an option to ignore extra attributes and elements, so additions to a schema need not break an application. missing elements on the otherhand, will still throw exceptions in castor, so in a "unreliable" situation, I'd totally agree a mapping approach is more flexible. though, I think the approach JiBX uses may provide similar level of flexiblity to mapping approach, while still using binding techniques. just some random thoughts. I've also used both approaches and both have their strengths and weaknesses.If I remember correctly, JAXB started way back in 2000/2001 and stalled for over a year. I think the original RI took a different approach. When JAXB work started up again, they went with the current approach. My memory is foggy, so I could be wrong.peter

Caveat: I'm only familiar with the first version of JAXB.My problem is not with tools that allow you to bind XML to custom Object heirarchies. I think that is a really effective strategy, if you can pull it off.My problem is with generating classes that match the XML schema. This is an asinine apporach, IMO, becuse desinging a schema and designing Java class relationships are two very different things.

can't argue with that statement, since I've seen people model objects like XML and realize it didn't work the way they thought. it gets worse than that. I know plenty of .NET developers who create a database model, then use VS.NET to generate a schema from the tables. Then they generate the classes using XSD. usually, within a couple of days, they start changing the schema when it doesn't meet the needs. Then they start moaning about mapping between the database table and the objects. At that point, it becomes painfully clear modeling domain objects in Java/C# is very different than creating db model or xml model.

oh well that's life.

This thread makes a lot of sense. IMO, the primary problem with developers in the Java/C++ domain is that they don't understand very well the difference between Object Oriented development and Object based development. Most developers now think that if they can somehow create some classes (objects) they have succeeded in OO development.
This leads to coupling of technologies not really intended.

Regards,
-Arindam

Just like DTO's for SQL databases.

Actually it's not like DTOs for Databases. Even if the DTOs are originally based on the DB schemas (a questionable practice from my personal experience), you are not bound by that correlation. You can change a DAO to match a new DB schema without changing the DTO. If you generate an Object model using a tool like JAXB, changing the schema means changing the Object model and often changing all the code that is associated to that Object model.

You know you made a good thoughtful point about XML binding.

But your point resonates throughout application development. Objects have many many possible roles and representations not just M, V, or C. XML or SQL, UI, Business Object or Asynchronouos Message.

We are stuck in the object world with coupling and binding issues because we want to layer everything and yet have everything act seemlessly as if wasnt layered.

Layers and disparate representations add many orders of complexity and opportunities for error and translation and performance problems so what have we gained?

Well, we have multiple representations and layers...thats it.

Why do we want these things in the first place?

Because our tools dont yet have a multi-dimensional concept of what needs to be done in my opinion. So we all sit around bitching about the lack of best-case integration. (And no, Im not implying aspect programming will solve anything here)

I hope 10-15 years from now there is a programming framework, idiom or language which can solve all these silly issues. They really waste our time in terms of learning and needlessly forming allegiances to transient anti-matter and marketing strategies.

If you tightly couple to your decoupling mechanism, then you have to either create a different decoupling mechanism, or you end up with a brittle coupling between your systems.

I think you really nailed it there (no pun intended).

By default, XMLBeans just makes you a jar file, but there is an option to generate source.

Loose XML ??

What about when you have a large number of optional tags and/or attributes. Don't the code generation approaches try to generate classes to handle all combinations.

Coupling your application's architecture to a binding framework may not be desirable given the many options and varying performance differences.

Although I'm not naive enough to think that converting from one api to another is a matter of flipping a switch, you may want to consider something like the DBO pattern posted here on TSS: http://www.theserverside.com/patterns/thread.tss?thread_id=19361

A little dated as it was written a couple of years ago, it really is just a combination of various well known patterns, but might save you some headaches in the long run should you decide to switch....

There is complainment about Castor generating one long xml string by default. But this can be easily changed in property file(org.exolab.castor.indent=true
). I don't think this should be stated as disadvantage. Default is most suitable for production. Who wants additional whitespaces in production (regarding the length of xml files)?

Tomas

... that such performance and memory consumption results are useless. But, hey: maybe I will remember this report when I have to (un-)marshall XML files with 1.11KB, 60 lines and 7 levels deep on a Pentium 4 2.4MHz machine with 512MB RAM using JDK 5.0 :-)

Further, the "ease of use" comparision appears to me to be quite subjetive. A more detailed comparision of the features provided by the different frameworks would have been better.

Nevertheless, at least this report provides a large list of XML binding (XML serialization, resp.) frameworks, so I can make up my mind on them myself :-)

Regards,
    Dirk

Further, the "ease of use" comparision appears to me to be quite subjetive. A more detailed comparision of the features provided by the different frameworks would have been better.

Agreed.

I would have like to have seen a standard set of perhaps 100 "ease of use" conditions, rather than a some what random selection of idle thoughts about each tool.

I know XStream is a great tool, but I'm wondering how they gave it no good (green) points and 3 bad (red) points and still rated it 7/10!

And hey, IO received two good (green) points. Surely that means it should be joint third with Glue, and XMLBeans!

Come on guys, lets be a bit more scientific in this section of the tests!

I'm surprised that they did not check JDO implementations that can do XML mapping as underlying data storage.

Does TopLink do the same thing?

Yes TopLink supports Object/XML binding as part of the 10.1.3 release. The latest developer preview can be downloaded from OTN (http://www.oracle.com/technology/products/ias/toplink/preview/10.1.3dp3/index.html). It is JAXB 1.0 compliant but goes beyond by allowing user defined objects to be mapped directly to existing XML schemas (avoiding the anemic domain model pattern) . XPath queries are used in the mappings to associate object attributes with XML data; this breaks the need for there to be a 1-to-1 correspondence between the object model and the XML document. Mapping metadata can be created visually using the TopLink Mapping Workbench or programmatically. Object/XML mapping can also be combined with TopLink's Object/Relational mapping so that the same objects can be read from/written to both XML documents and relational databases.

Does TopLink do the same thing?

Unknown. However, take a look at xcalia's LiDO product. It is the only JDO implementation I know of supporting persistence to XML.

Having said that, I'd love to see it in with the benchmarks here.

LiDO is for-pay, and a great implementation. Does anyone know of any open source JDO implementations supporting (or planning to support) O-X? I for one would begin using it right now, if I found out about its existence.

Best,

- Chris

I'd love to see [Xcalia's LiDO XML] in with the benchmarks here.

Well, ask and I shall recieve ;-)

As if my wish above had been instantaneously granted, I just found this on the BindMark site:

"Expect the following libraries to be added shortly: LiDO XML, ActiveXML, XGen and Eclipse EMF."

Excellent!

- Chris

Chris Beams
http://chrisbeams.com/blog

Wow... That would be interesion to see how JDO compares...

since the xml stream parser and xpp are available, why not also run benchmarks with those parsers. JSR 173 http://www.jcp.org/en/jsr/detail?id=173 was approved back in october 2003, and it looks like JWSDP 1.5 http://java.sun.com/webservices/jwsdp/index.jsp will ship with a stream parser.

If the benchmark includes stream parser results with the drivers that support it, it would be beneficial to state that explicitly. I couldn't tell from reading the article. I do see crimson mentioned as one of the parsers used.

peter

I actually authored and XML to/from Java framework which I have open sourced (meaning take, use it, hack it or ignore it as you will). It started off as merely wanting to read and write configuration files that needed to be more robust than property files. It's grown in use into something that can easily generate object graphs from XML that we swap around with our business partners in my day job. It's not very clean code as it doesn't get near the time it should and it's certainly not as feature robust as many of the frameworks mentioned here, but it serves us well.

I'm sure many, many projects have no use for XML at all, but it's been very useful for me and for many of the projects I've worked on. I think it might be a little shortsighted to simply dismiss the technology as a whole.

I actually authored and XML to/from Java framework which I have open sourced (meaning take, use it, hack it or ignore it as you will). It started off as merely wanting to read and write configuration files that needed to be more robust than property files. It's grown in use into something that can easily generate object graphs from XML that we swap around with our business partners in my day job. It's not very clean code as it doesn't get near the time it should and it's certainly not as feature robust as many of the frameworks mentioned here, but it serves us well.I'm sure many, many projects have no use for XML at all, but it's been very useful for me and for many of the projects I've worked on. I think it might be a little shortsighted to simply dismiss the technology as a whole.

What's the project? Is it basically a way to map XML to existing Objects?

http://www.bifrost.org/xmlio

It's just a simple way of going from XML to/from existing Java objects. It maps to objects that are structured the same way I'd structure any other simple data object; that was a very important requirement for me.

By default it'll use element names that exactly match object and property names, but you can set up a mapping between names if you must. It's simple but works for me and a few others using it. Your mileage may vary...

http://www.bifrost.org/xmlioIt's just a simple way of going from XML to/from existing Java objects. It maps to objects that are structured the same way I'd structure any other simple data object; that was a very important requirement for me.By default it'll use element names that exactly match object and property names, but you can set up a mapping between names if you must. It's simple but works for me and a few others using it. Your mileage may vary...

This is similar to something I've been kicking around in my head. And it looks like a good start. Are you interested in contributions/ideas?

Sure, I always welcome ideas, contributions, code review, etc. Email me (link on the site) and we can take this private.