Serializing Java Objects with XStream

Discussions

News: Serializing Java Objects with XStream

  1. Serializing Java Objects with XStream (43 messages)

    XStream is an open-source Java library for serializing objects into XML and deserializing that XML into objects. Unlike other APIs, such as David Megginson's XMLWriter or Elliotte Rusty Harold's XOM, which use specific classes and methods to produce XML, XStream relies on Java idioms such as object names to produce element names and strings within classes to produce element content. It also produces a kind of reflection of objects in XML.

    Conclusion
    This article has introduced you to the basic features and capabilities of XStream. For additional insights, you might have a look at XStream test programs that use maps or collections (from the test suite). There is plenty of CVS activity, enough to give me hope that XStream is in active development and will be around for awhile. I think XStream takes a nifty approach to XML serialization and persistence, and I'll be keeping my eye on it for even more innovation in the future.
    Serializing Java Objects with XStream

    Threaded Messages (43)

  2. We are using XStream to export our serialized Java database in order to do long-term storage and schema migration (export Java objects->XSL to transform to new format->import into Java objects). The default reflection rules work very well, and whenever you want to tweak something it is easy to do. Much recommended.
  3. We used XStream similarly to transform an external XML file to an intermediate XStream format and import that as Java objects. I had less luck going the other way though since you can't really control the extent of the object graph you want to export.
  4. JDK XMLEncoder[ Go to top ]

    If you have access to JDK1.4.0 or greater then just use XMLEncoder/Decoder for java Object serialization.
  5. JDK XMLEncoder[ Go to top ]

    XML{En,De}coder is only limited to JavaBeans.
  6. Agree[ Go to top ]

    I agree with you. For example:

    String test = "aaabbbccc";
    ByteArrayOutputStream output = new ByteArrayOutputStream();
    XMLEncoder enc = new XMLEncoder(output);
    enc.writeObject(test);
    enc.close();
    System.out.println(output.toString());
  7. XMLEncode/Decode, XStream[ Go to top ]

    XMLEncode/Decode does not handle enums properly in java 5, unlike XStream. The bug is fixed (so I am told) in java 6.
  8. --Siva
  9. Castor is more stingent when we try to comply with XSD etc.

    The classes castor generates are big when we create source that complies with castor.

    XStream leaves a ligher footprint when doing conversion from javaobject to xml. But we have to do our own xsd compliance though.
  10. Impressed[ Go to top ]

    We use XStream as a object -> XML tool for our in house XSLServlet. We have been very happy with its performance and flexibility. It has allowed us to created reuseable Java objects, that represent visual html components, then we just feed the objects to our XSLServlet. Inside our XSLServlet XStream converts the objects to XML, and then we just apply the proper stylesheets.
  11. Really nice tool[ Go to top ]

    I love XStream. Once I got my hands on it I replaced my old homegrown system for object serializationw with it. Great job.

    The article itself is plain useless. Even the short tutorial offers more informations then this article. The examples are hilarious. Anyway even this kind of pr is better then nothing.
  12. Be aware of the website. It was down for almost all the day sometime last week.

    Make sure u download the javadocs along with xstream jar. So that u won't regret later.
  13. Jakarta Commons Betwixt[ Go to top ]

    Looks pretty similar to the Betwixt project.
    Has anyone used both and can compare the two?
  14. Jakarta Commons Betwixt[ Go to top ]

    It's in the faq.txt if you download xstream.
  15. xstream rocks[ Go to top ]

    I've been using XStream and did some informal benchmarks for myself. XStream with XPP3 uses considerably less CPU than either crimson or xalan/xerces. Thanks to the xstream team.
  16. XStream Prevayler snapshot manager[ Go to top ]

    I used XStream to implement a custom Prevayler snapshot manager. It gets around two issues that can be a bit annoying with the pure java serialisation snapshot manager:
    1. With XStream your classes no longer have to implement Serializable, though XStream has its own restrictions in enhanced mode most of these vanish.
    2. Since the snapshot will be in XML format it can easily be transformed to a new format when your object model changes, this is tricky with java serialisation.
  17. XStream vs JSX[ Go to top ]

    Why would anyone use JSX (http://jsx.org/index.html) if there is already XStream ? Does anyone know how the two compare ?
  18. XStream vs JSX[ Go to top ]

    Just downloaded xstream and found the answer in the faq.txt
  19. XStream vs JSX[ Go to top ]

    freeJSX is open source (free), has shorter XML than XStream, and handles all objects. XStream does not work for all objects. That's why customers have paid thousands of dollars for this version of JSX.<BR>
    http://www.csse.monash.edu.au/~bren/JSX/
    <P>

    JSX predates XStream by many years, which is why it is a much more mature product than XStream. JSX began in 2000, and its first commercial sale was in October 2001 - XStream started 2 years later, in November 2003.
    <P>

    XStream's faq entry for JSX is plainly incorrect - I've pointed this out to Joe Walnes that he has made false claims about JSX, but he hasn't changed the faq. This is extremely dishonest.
    <P>

    XStream does not handle all objects. Joe Walnes actually admits this on his own home page - but not on the XStream website: <BR>
    XSTREAM Problem: [...] there are many classes (particularly in the standard java and javax packages) that rely on advanced features of the serialization API, by implementing the methods, readObject(), writeObject(), writeReplace() or the methods found in java.io.Externalizable.<BR>
    http://joe.truemesh.com/blog//000358.html
    <P>

    You have to discover these limitations of XStream for yourself, as many of his users have, which is revealed by his issue tracker.
    <P>

    It was a severe effort to make JSX work for all objects; and so when XStream arrives and makes falses claims, without doing the work, it makes me lose respect for the project. Especially when many users are being mislead by the claims.
    <P>

    Joe Walnes will make a public retraction on the XStream website, if he believes in honesty and integrity, and wishes to build a reputation for those qualities. The way he is promotely XStream is extremely dishonest. This is what is most "xstream" about it.
    <P>

    In fact, Joe Walnes is contravening basic consumer laws against "deceptive and misleading advertising". Both Thoughtworks (com.thoughtworks.xstream is the package name) and codehaus (who hosts xstream) are parties to this fraud, and both are commercial, for-profit corporations - and both stand to benefit from this deception.
    <P>

    XStream is a good product for configurable XML; and it is a shame that Joe Walnes cannot be happy with that, and feels compelled to make false claims against other products that have achieved what he has not.
  20. XStream vs JSX[ Go to top ]

    Here's a reason for xstream over jsx:

    XStream -> BSD
    JSX -> GPL
  21. XStream vs JSX[ Go to top ]

    Here's a reason for xstream over jsx:
    XStream -> BSD
    JSX -> GPL
    Both are free open source licenses... if BSD vs. GPL is a real reason to
    choose it, then it's in serious trouble! Most people evaluate technology
    products on the technical merits - especially when there is a such wide gulf in
    basic abilities and architectures, as is the case here.


    XStream doesn't seem to be "BSD", anyway: the readme title is "(BSD Style License)". How does this differ from a BSD license? Does it matter? I don't know.

    freeJSX is just plain old GPL - same as Linux and mySQL. A well-known, well-established license, with no surprises.

    You can use freeJSX as freely as Linux.
  22. XStream vs JSX[ Go to top ]

    freeJSX is just plain old GPL - same as Linux and mySQL. A well-known, well-established license, with no surprises.
    That's a false claim. GPL has surprises compared to BSD license.

    Regards.
  23. XStream vs JSX[ Go to top ]

    Technical capability is just one aspect of evaluating technology, an important one, though, I agree.

    However, this is a library we're talking about, and using it with an app you redistribute would require the app to be GPLed as well. The BSD variant wouldn't. Some people care, others don't.

    The linux/mysql comparison is not quite accurate, as you generally use them, not link/embed them.

    --peter
  24. XStream vs JSX[ Go to top ]

    However, this is a library we're talking about, and using it with an app you redistribute would require the app to be GPLed as well. The BSD variant wouldn't. Some people care, others don't.The linux/mysql comparison is not quite accurate, as you generally use them, not link/embed them.--peter
    Most software is developed for in-house use, not for distribution. The figures I've seen are that about 95% of developers work in-house. I doubt anyone knows the exact figure, but it seems undisputed that most is in-house.

    The mySQL business model is based on dual licensing GPL code. That is, distribution of GPL code in a non-GPL requires a second commercial license (hence "dual" licensing). Berkley DB is another embedded GPL database with this business model.

    Both a database and library can be distributed as an embedded component, and so
    in this context, they are equivalent.

    Linux is also distibuted as an embedded component, for example, in specialized hardware, some PDA's and cell phones.

    The JVM itself (a platform) is distributed in a similar way.

    For most developers, GPL is free. A business wishing to redistribute commercially (that is, make money from it) needs a commercial license. In effect, this subsidizes the free users.

    I think the mySQL comparison is perfectly accurate; but I agree that Linux isn't a perfect analogy to freeJSX (JSX1). However, as the most well-known GPL product in the world, it seems reasonable to mention it when the GPL is concerned, to show how well-known the GPL is.


    note:
    JSX1 (freeJSX) is GPL.
    JSX2 is commercial + free for academic use (not open source)
  25. XStream vs JSX[ Go to top ]

    The GPL is a poison pill for commercial software development. You would have to make your source code available in order to distribute the free version of JSX with your binaries.

    That may be why free JSX was released under the GPL. They probably figure that if you are using JSX for commercial work they deserve to be paid for their work too. Nothing wrong with that.
  26. XStream works great[ Go to top ]

    I've almost completed a project where we used XStream as the way to persist a configuration for a large web app to and from XML.

    One thing you need to consider is that in default mode XStream is not JVM neutral. This has some ramifications if you are using it on the server-side and may use JRocket for example. XStream works in the more powerful by using some (undocumented?) tricks available only in the Sun JVM. I don't know if there is a risk of this trick going away in a future version of the JVM.

    You can switch to a JVM-neutral mode which puts some limits on the kinds of objects you can serialize.

    There are subtle differences between the two modes. Like in default mode, none of the objects constructors are called when unmarshalling whereas in the JVM compatible the default constructor (which is required in this mode) is called.

    This means that if you have transient fields that need to get initialized, you can put that code in the constructor in the non-default mode but need to have some kind of init() method on objects deserialized in default mode.

    All this is well documented in the XStream FAQ but it was worth mentioning here. Don't get me wrong, I think XStream is one of the easiest of these kind of tools and will probably use it on many more projects.
  27. JSX License is worse than GPL![ Go to top ]

    Here is an exceprt from the license, and the reason we didnt buy it.

    http://www.jsx.org/license/CreditCard_1.9_JSXlicense.pdf

    "This license does not allow you to give the right to other people to distribute or use JSX."

    If you read on in the license you will understand that you must buy a license for each separate person distributing your software!!! Also - you must buy a new license for each piece of software you release! Thats insane! Why cant they just have a standard license - then they would be sweet.

    XStream works for 99% of all objects you actually need to serialise in our experience. We actually ported from JSX (demo) to XStream and found this figure for our application domain. Its trivial to write converters for the rest.

    Also - if you look at the two code bases (XStream vx freeJSX) you can definitely see who understands good design. Native Java Object serialisation is a mess - have a look at the code and see why. XStream is a better solution in the longer term as you have more control.

    JSX is obviously scared of XStream - they only recently revived freeJSX, and according to the above they are reading XStreams website, issue trackers etc.

    Then they are complaining about advertising!

    Chill eh! Competition is good.
  28. JSX License[ Go to top ]

    Hi Ana,

    Thanks for raising this issue, and I'm sorry about the misunderstanding - of course you can distribute your app in any way you please! The above is just saying that you can't set up shop as a reseller of JSX, and redistribute it directly.
    "This license does not allow you to give the right to other people to distribute or use JSX."If you read on in the license you will understand that you must buy a license for each separate person distributing your software!!!
    The above line is only the preamble, not part of the license itself (ironically , the preamble is supposed to clarify the license). I entirely agree, it needs to much clearer! Thanks for raising this issue; it's appreciated very much.


    For clarity:
    You can distribute JSX (provided it is within your product) though your regular channels and multiple tiers of distribution, including without limitation, resellers, distributors, VARs and OEMs, to end-users or directly to end-users.
    The above text is not yet incorporated into the JSX commmercial license, but it will be, as soon as we are sure that it does actually clarify your specific concern. Please note that this is clarification of what was already intended.

    I would much appreciate discussing it with you, to confirm that it is really is
    clearer:
      jsx(at)jsx.org



    Design: JSX2 has a very clean architecture. JSX1 is a prototype that was pushed though right to the end - and so it has the design of a prototype. The next step in development was a simpler redesign for a chapter of "Professional Java XML" (Wrox, 2001 - yes, a while back):
    http://www.amazon.com/exec/obidos/tg/detail/-/186100401X/103-9811017-5919053?v=glance
    Source is available at: http://freshmeat.net/projects/hammer/

    We tried out a few different architectural designs for JSX2 before settling on the best one (in 2002).

    100% compatibilty between the Java Serialization standard and XML is difficult
    to achieve, and so having a complete (albeit messy) example like JSX1 was essential - how to solve a problem without first understanding it?

    JSX1 is about understanding the problem; JSX2 is about solving it.


    BTW: "Ana Theeson" doesn't turn up on any Google searches apart from your above post...
    http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=%22ana+theeson%22
    We've noticed this with another XStream supporter... who also expressed some unhappy misunderstandings about JSX on our mailing list. Unfortunately, he
    didn't reply to emails to his account - which was created on the same day
    as his post...

    Ana, I'd much appreciate it if you would contact us directly, so we can address your concerns. I think you might be glad to help make sure suitable changes are made to clarify the confusion you experienced with the license:
       jsx(AT)jsx.org

    No, we don't think you'll change you mind!! We just want to rectify the specific problem you raised. Although they are notoriously difficult to achieve in legal documents, we value clarity and simplicity.
  29. Re - License[ Go to top ]

    Thanks for the reply. I was shocked reading the license and thats why the company I work for didn't use it.

    Thanks for clarifying the license issues, if I hadnt already gone to xstream I might have used it.

    Its strange I don't turn up - im registered on a few boards and recently posted on theserverside.net. Im usually quiet, but when I read the license of JSX I was outraged. Typical of a non-lawyer type like me to mis-interpret.

    Sorry for the comments- i really was angry with the license.

    Regards,
    Ana
  30. It should be noted that JSX is no longer for sale or supported for previous purchasers and the freeJSX website says it is also no longer available.
  31. JSX is available[ Go to top ]

    JSX is available, and has been throughout 2006. It is supported - at no time have purchasers have been without support.
  32. Re: XStream vs JSX[ Go to top ]

    The inaccuracies/omissions in XStream's (then) FAQ were clearly honest mistakes, and I apologise to Joe Walnes for suggesting otherwise.
  33. XStream limitation[ Go to top ]

    From the faq.txt,

      "XStream has a limitation: it cannot handle cyclical links."

    Is there any intention in the development team to overcome this limitation ?

    Are there any other limitations when compared to JSX ?

    If not, it seems pointless to use a payware (JSX) when one can get a freebies (XStream).
  34. XStream limitation[ Go to top ]

    One thought of overcoming the cyclical limitation is that once a cyclical reference is detected, instead of generating the XML subtree for the cyclical content, simply generate a special child containing the XPath referring to the already existent element in the XML file.

    Good idea ?
  35. XStream limitation - no more[ Go to top ]

    Hi,

    The faq.txt that comes bundled with XStream is wrong. It's out of date and should have been replaced. Refer to the FAQ on the website for more information. Please disregard anything in faq.txt as it was a just a temporary file of notes and questions to be one day turned into the real FAQ. I apologise for any confusion this causes.

    XStream fully supports cyclical links and has done since 1.0 was released a few months ago. If an object reference is encountered that has already been seen in the object graph, XStream will insert an XPath expression to refer back to it.

    As for how XStream compares to XMLEncoder, JAXB, Castor, JSX, FreeJSX, Betwixt, etc... Any answer you get from me is going to be biased! :)
  36. Another one[ Go to top ]

    Skaringa is another java to xml serialization framework. I used it with Prevalyer, and it's very fast.

    http://skaringa.sourceforge.net/
  37. Another one - part2[ Go to top ]

    damn, hit the reply button too fast, there was more:

    It has been a while though, and XStream sure looks nice. I will definitely check it out.

    Keep up the good work.
  38. TRAX support missing[ Go to top ]

    Due to the fact that the XML output format is mainly fixed (except for the alias feature), if I use it I will definitively pipe the output with an XSLT transformation (in general the XML is given from the outside world)

    But it seams that Xtream lack some Trax support (Source and Result)


    P.S. Actually I realized that it has TraxSource on the last snapshot, but no TraxResult...
  39. Some clarifications[ Go to top ]

    XStream is a tool intended for serialization of Java objects to and from XML automatically without the need for custom mapping. This is true for most objects, but not all.

    XStream 1.0 has a limitation that it cannot serialize objects that override the default serialization mechanism by defining readObject(), writeObject() or writeReplace() methods, or that implement Externalizable. A future version of XStream (most likely 1.1) will not have this limitation.

    The entries in faq.txt were never intended to be made available to the public (as stated in my post above). This file contains some unclear information which was later clarified on the public mailing list. Unfortunately this clarification was never made to the faq.txt file as I forgot about its existence. I have subsequently deleted this file.

    To clarify some statements in the faq.txt file:

    1. "JSX produces more verbose XML".
       This should read:
       "JSX1 produces compact XML. JSX2 produces more verbose XML".

    2. "JSX is commercial payware".
       This should read:
       "JSX1 is opensource licensed under the GPL. JSX2 is commercial payware (and free for academic use)".

    3. "JSX can serialize *anything* that standard Java serialization can."
       This statement should be discarded altogether.

    As you can see, the distinction between JSX, freeJSX, JSX1 and JSX2 is very important. Googling for JSX should clarify the discrepencies.
  40. Great News[ Go to top ]

    Joe,

    Thanks for all the great work. When do you think 1.1 will be available?

    I know many of groups who will switch from using other serialisation as soon as xstream supports this.

    I have gone through all the API's (JOS, XStream, JSX, BetWixt, Skaringa etc) and your approach is very well thought out and well designed. The worst of the lot is probably native serialisation. Its just ugly.

    It will be interesting to see what potential improvements the community will come up with for xstream once it hits the prime time.

    A good, free as in do-with-as-you-want xml serialisation routine is a long time coming.

    Regards,
    Ana Theeson
  41. XML serialization in the Java framework isn't nearly as advanced as in the .Net framework, and I'm happy to see some folks advancing the XML cause over in Javaland with open source (BSD) projects.

    The one tweak I'd like to see in this library is the use of attribute based coding techniques (a la .Net) for XML serialization. What arethe advantages? Instead of using the alias method to supplement the reflection info (and to control the serialization), you add that info to the classes that you are serializating (where it belongs) via attributes. It is a much cleaner (and easier to maintain) architecture.

    Here' my blog entry on this topic: http://donxml.com/allthingstechie/archive/2004/08/24/1222.aspx
  42. Great News[ Go to top ]

    Joe,Thanks for all the great work. When do you think 1.1 will be available?
    1.1 will most likely be available in the next 6 weeks.

    If you are desperate for full serialization support, you could try out the latest snapshot version from CVS as this now supports many of the Java serialization hooks.

     * Support for java.io.Externalizable.
     * Support for readResolve() and writeReplace().
     * Partial support for readObject() and writeObject().

    When I say 'partial', the snapshot handles the most common usages of readObject(), writeObject() however it has a few limitations:

     * It does not correctly deal with objects that use the advanced readFields()/putFields() of the object streams. In the entire 1.4.2 JDK there are only 7 classes that actually use this.
     * It does not deal with the case where readObject()/writeObject() appear multiple times in an inheritance heirarchy.

    Both of these are limitations that I intend to overcome by the 1.1 release.

    The snapshot with these new features in is available from the download page:
    http://xstream.codehaus.org/download.html

    [Disclaimer: The format of the XML for produced for objects implementing these serialization hooks may differ between the snapshot and the final 1.1 release].

    Thanks
    -Joe
  43. and Trax?[ Go to top ]

    Joe,

      And what about that Trax support that there's already on latest snapshot? Is it planned for a 1.0.x version or we'll have to wait untill 1.1?

      We're using castor-xml to generate pdfs with xml + xsl + fop. We would like to reduce the footprint of our apps getting rid of castor in favour of xstream but we cannot do it until stable Trax is available.

      cheers!
  44. This posting is about 'Serializing Java Objects with Xstream.' I like knowing more about Java related stuff. I think Java scripting is important for those indulged in websites development. It is good to know that XStream is an open-source Java library for serializing objects into XML. Many like Java and XML as they are popular for websites creation. One of the comments state that stream is a tool intended for serialization of Java objects to and from XML automatically. Dedicated server is needed for all hosting companies.

    Paul - http://www.connetu.com