I'm pleased to announce the release of XStream 1.1.

XStream is a simple library to serialize objects to XML and back again.

New features include:

Improved support for serializing objects following the Java Serialization Specification:

  Calls custom serialization methods, readObject(), writeObject(), readResolve() and writeReplace() in class, if defined.

  Supports ObjectInputStream.getFields() and ObjectOutputStream.putFields() in custom serialization.

Provides implementations of ObjectInputStream and ObjectOutputStream, allowing drop in replacements for standard serialization, including support for streams of objects.

Reads and writes directly to most XML Java APIs: DOM, DOM4J, JDOM, XOM, Electric XML, StAX, Trax (write only), SAX (write only).

Homepage : http://xstream.codehaus.org/
Changelog: http://xstream.codehaus.org/changes.html
Download : http://xstream.codehaus.org/download.html

I have to say thanks for XStream. I've been recommending it to my friends and JMeter uses XStream in the current CVS HEAD. Your hard work is appreciated.

peter

The simple XML-to-Object library just got more powerful while remaning just as easy to use! What's with that? Whay can't everything be this great!

Just wondering... Couldn't find it on their website.

I believe currently it doesn't provide that functionality. though it should be feasible to use either jaxb or jaxme to generate the classes and use XStream. I haven't tried it, so not sure if that really would works.

xstream is a object graph serialization tool not java/xml binding tool so u cannot give xsd and generate java classes, however u can to some extent customise the xml format if u want. if u want an XSD for this xml to use with a validating parser ,u can use the inst2xsd tool which included with apache xmlbean ver 2(cvs only)

Thank you Joe!

XSTREAM IS A OBJECT GRAPH SERIALIZATION TOOL NOT JAVA/XML BINDING TOOL

I cannot tell you how often I have seen developers run into problems because they do not understand the difference.

I guess when most problems arise it is because developers do not understand the problem definition in the first place anyways ;)

In my experience - I think most software developers are well trained to interpet object models and write code, but how it often relates to xml and when and where the appropriate tools does not get the proper justice.

Just my two cents on top of Joe's well said words.

Thanks!
~tim

Point taken. However, in my case (for messaging purposes) I would want to serialize the entire object to xml, and send inter-platform messages, so it is nice to be able to turn on validation as one of the steps to analyse possible communication problems between the two systems. So if I use castor, and write an xsd I can generate the java objects, have validation and serialization/deserialization (marchalling/unmarchalling); one stop stop, which saves development time.

I was thinking xstream would maybe give me a boost in performance in the serialization/deserialization step? Is this such a 'wrong' thought?

thx,

--Kurt

Hi there!

I certainly do not think that this is a 'wrong' thought kurt. Your use of xstream would perhaps exemplify what it is best used for.

My thoughts were not so much pointed at you but others from my own experience (hopefully they will read this) who have tried to use brute force to make one package support the purpose of another.

I have been prototyping xstream with a JAXB implementation of mine. I would be curious to see how the run times compare.

Thanks for the feedback!
~tim

Hello,
So without my going out and trying this, can someone tell me how this is different from java.beans.XMLEncoder/XMLDecoder in jdk 1.4.x?

They both seem to be doing the same thing, serializing JavaObjects. What am I missing?

TIA,
Pankaj

So without my going out and trying this, can someone tell me how this is different from java.beans.XMLEncoder/XMLDecoder in jdk 1.4.x? They both seem to be doing the same thing, serializing JavaObjects. What am I missing?

You don't have to try it .. just look at the docs:

XStream:
http://xstream.codehaus.org/tutorial.html

XmlEncoder:
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLEncoder.html

First, you can see that one (XStream) is trying to "plug in" as simply as Java object serialization, and the other (Sun) is totally a custom interface vis-a-vis Java object serialization.

Second, you can compare the resulting XML. (Again, see the two links above.)

I've never used either. However, based on a two-second perusal of the docs, for Java object serialization it's pretty easy for me to figure out which is preferable: XStream.

Peace,

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

First, you can see that one (XStream) is trying to "plug in" as simply as Java object serialization, and the other (Sun) is totally a custom interface vis-a-vis Java object serialization.

Cameron, I don't think you're right on this one. The XMLEncoder (and XMLDecoder) encodes (and decodes) JavaBeans only, not arbitrary POJOs like XStream. However, one should take care when developing with XStream for multiple platforms, since the default behavior relies on Sun JVM specifics, so the code may not be portable to e.g. an IBM JVM.

Nils

Cameron, I don't think you're right on this one.

In light of your suggestion, I think it tilts the favor more toward something like XStream (for the explicit purpose of Java serialization to/from XML, but not at all for Java object mapping to/from XML).

Peace,

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

Cameron, I don't think you're right on this one. The XMLEncoder (and XMLDecoder) encodes (and decodes) JavaBeans only, not arbitrary POJOs like XStream. However, one should take care when developing with XStream for multiple platforms, since the default behavior relies on Sun JVM specifics, so the code may not be portable to e.g. an IBM JVM.Nils

I was "kind of" ok with Cameron's answer till you brought up the above :)

Firstly, altho the XMLEncoder and XMLDecoder are packaged with the java.beans.* package (and it DOES say in the API javadoc that it is used to encode and decode Javabeans), the writeObject() and readObject() methods do seem to deal with Objects.
Infact, this led me to a more fundamental question: What specifies that a class is a JavaBean? The host of interfaces (BeanInfo, *Events etc.) that come along with the JavaBeans "concept" are really used to embed this JavaBean in a GUI. In the simplest sense, therefore, a JavaBean can be defined as a serializable POJO with a bunch of private member variables and setters/getters.

I have successfully used XMLDecoder and XMLEncoder on such a JavaBean/POJO.

So what then can XMLEncoder/XMLDecoder NOT accomplish? XML conversion of classes with behaviour? (I wouldn't call such classes a POJO but that is besides the point). I am not able to think why someone would like to represent such a behaviour heavy class, in XML. Can someone please enlighten?

If I am willing to go with a custom XML (as Cameron puts it) then I really have a complete solution within the Sun supplied java.beans.* classes.

Which brings me to my second question. Why is it that a implementation offered by Sun (java.beans.XMLEncoder as part of JDK1.4) is NOT tied to Sun JVM specifics and the implementation provided by XStream, an independent vendor, IS Sun JVM specific?


TIA

Pankaj

flames >> /dev/null
:)

What specifies that a class is a JavaBean?

It needs to be serializable, have a default constructor, and have at least one getter or setter.

In the simplest sense, therefore, a JavaBean can be defined as a serializable POJO with a bunch of private member variables and setters/getters.

According to this Wiki, no:
http://c2.com/cgi/wiki?PlainOldJavaObject

I have successfully used XMLDecoder and XMLEncoder on such a JavaBean/POJO.So what then can XMLEncoder/XMLDecoder NOT accomplish?

Encoding/decoding of objects that are not JavaBeans.

XML conversion of classes with behaviour? (I wouldn't call such classes a POJO

But they are :-)

Why is it that a implementation offered by Sun (java.beans.XMLEncoder as part of JDK1.4) is NOT tied to Sun JVM specifics and the implementation provided by XStream, an independent vendor, IS Sun JVM specific?

XStream is not Sun JVM specific per se. Its default behavior is (bad thing, IMO). To avoid Sun JVM specific behavior, use new XStream(new PureJavaReflectionProvider()) as stated somewhere in their docs.

Nils

Hi. I have problems with encoding value object without default constructor (no-argument). Can anyone has an idea how can I go about this? Apparently, we have a lot of value objects without the default constructor. Thanks

If you think there's a common confusion between these two and yet a clear reason for distinguishing between them, perhaps you should take the time (here/elsewhere) to make that distinction in the hopes of clearing up?

Okay, only one thing remains to make this a perfect tool - support the j# compiler for .NET and the XML APIs that are available for .NET.

Up to now I've been defining my objects in XSD, using JAXB to generate Java-side bindings and XsdObjGen to generate C# .NET bindings. That works because can support object graphs and supports bi-directional marshalling of objects.

However, Java is my flag ship language and what I'd really like to do is serialize Java objects to the .NET side. That is, all the object classes that are marshaled would be defined in terms of Java classes.

A combination of a tool like XStream and the j# compiler could in theory do the trick.

Now j# can compile source from old j++ - what remains is to see if XStream could generate java code that is compatible to the java class libraries as they existed in j++ release. And then the XML APIs that are used would need to be based on what is available in .NET.

If you use the J# conversion tool, it can take a jar and generate a DLL. The generated DLL can then be used like any other dll. the other option is to use IKVM. Or you could just import the source code and compile it in the latest J#.

peter

looks good, but before I go off and try this out, does anyone know the performance comparison between this and the similar features within Glue?

I've done some quick informal benchmarks using XStream and it's pretty darn fast. I compared it to Object input/output stream. when the xml is less than the equivalent objectoutputstream, XStream is faster. When the XML is larger, XStream takes longer obviously. The CPU and memory usage of XStream was pretty minimal. When I profiled it in OptimizeIt, the performance profile was minimal. I used XStream with XPP3.

peter

However, Java is my flag ship language and what I'd really like to do is serialize Java objects to the .NET side. That is, all the object classes that are marshaled would be defined in terms of Java classes.

Why not just use normal Java serialization?

http://blogs.msdn.com/DotNetInterop/archive/2004/12/10/279345.aspx

Hi Joe walnes ,
Please help me in this regard,
I am trying to create a object from a xml ,its giving error

Exception in thread "main" com.thoughtworks.xstream.converters.ConversionException: Cannot construct Person : null
---- Debugging information ----
line number : 1
required-type : Person
cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct Person : null
message : Cannot construct Person : null
class : Person
path : /person
-------------------------------
        at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:46)
        at com.thoughtworks.xstream.core.ReferenceByXPathUnmarshaller.convertAnother(ReferenceByXPathUnmarshaller.java:37)
        at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:96)
        at com.thoughtworks.xstream.core.ReferenceByXPathMarshallingStrategy.unmarshal(ReferenceByXPathMarshallingStrategy.java:12)
        at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:286)
        at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:274)
        at com.thoughtworks.xstream.XStream.fromXML(XStream.java:242)
        at com.thoughtworks.xstream.XStream.fromXML(XStream.java:233)
        at XstreamTest.main(XstreamTest.java:91)







I am pasting my code sniplet:


import com.thoughtworks.xstream.*;
import java.util.ArrayList;

 class Person {
   private String firstname;
   private String lastname;
   private PhoneNumber phone;
   private PhoneNumber fax;
   private ArrayList phoneList=new ArrayList();

   public Person()
   {

   }

   public Person(String s1,String s2)
   {
   firstname=s1;
   lastname=s2;

   }

   public void setPhone(PhoneNumber i)
   {

   phone=i;
   }
   public void setFax(PhoneNumber s2)
   {

   fax=s2;

}

   public void addToPhoneList(PhoneNumber s2)
{

phoneList.add(s2);

}


}

 class PhoneNumber {
private int code;
private String number;

public PhoneNumber()
{}

public PhoneNumber(int i,String s)
{

code=i;
number=s;


}



}


public class XstreamTest
{

   public static void main(String args[])
   {


XStream xstream = new XStream();

xstream.alias("person", Person.class);
xstream.alias("phonenumber", PhoneNumber.class);

Person joe = new Person("Joe", "Walnes");
joe.setPhone(new PhoneNumber(123, "1234-456"));
joe.setFax(new PhoneNumber(123, "9999-999"));


       joe.addToPhoneList(new PhoneNumber(456, "9999-999"));
       joe.addToPhoneList(new PhoneNumber(879, "9999-999"));



String xml = xstream.toXML(joe);
       System.out.println("Output xml string is :\n"+xml);


       Person newJoe = (Person)xstream.fromXML(xml);

       newJoe.addToPhoneList(new PhoneNumber(222, "9999-999"));
       newJoe.addToPhoneList(new PhoneNumber(555, "9999-999"));

       String xml1 = xstream.toXML(newJoe);
       System.out.println("New Output xml string is :\n"+xml1);
   }




}














Regards

Internally XStream is using reflection for deserialization. Due to the security mechanisms in place, only public classes can be instantiated.

Move your Person and PhoneNumber classes to their own source code files and make them public classes. It should work.

Thanks & Regards,
Ganesh Ravindran

Good Day,

This is just a question that I thought might be interesting. If a person is using XStream to convert the object hierarchy to XML, does anyone know of an XSLT that will produce an HTML of that hierarchy?

Regards,
Mark P Ashworth

Has anyone else had multithreaded problems with XStream. I was using v1.0 in some servlets that we were wrote for doing object->xml->xslt/html, but had to stop using it, because of excessive errors that we were getting under heavy load.

Has anything been fixed in v1.1 along these lines?

XStream has been designed to be thread safe, however this is always a tough one to test. A number of concurrency issues have been fixed in the 1.1 release. If you ever find any more, I will attempt to fix them as a high priority task.

I have used XStream in the past and it works very well for my needs.

Any plans on updating it to support Tiger soon ?

I tried to save an object stream with the new enum class, among other new features in Tiger, and it failed.

Thanks,

Peter

I have no problem serializing my classes but when I try to deserialize a class that contains an array for a class in the same package, I get a CannotResolveClassException on the contained class.

Works fine except for the bug that prevents you from deserializing an array. Can't imagine it pertains to all arrays or else I'm not sure how it passed its tests, but it revealed itself when I tried to deserialize an array of a custom class I wrote.

Hello,

In my project, it has an exception and I have been trying to find it for a month but I can't. Could you help me to find it( or what is the cause of this problem)

thanks,

com.thoughtworks.xstream.converters.ConversionException: Invalid final field java.util.Collections$SynchronizedMap.m : Invalid final field java.util.Collections$SynchronizedMap.m
 ---- Debugging information ----
 message             : Invalid final field java.util.Collections$SynchronizedMap.m
 cause-exception     : com.thoughtworks.xstream.converters.reflection.ObjectAccessException
 cause-message       : Invalid final field java.util.Collections$SynchronizedMap.m
 class               : java.util.HashMap
 required-type       : java.util.Collections$SynchronizedMap
 path                : /map/entry[6]/map/entry/object-array/java.util.Collections$SynchronizedMap/java.util.Collections$SynchronizedMap/default/m
 line number         : 355233
 -------------------------------
    at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:89)
     at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
     at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
     at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
     at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71)
     at com.thoughtworks.xstream.converters.collections.ArrayConverter.unmarshal(ArrayConverter.java:55)
     at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
     at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
     at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)

.......