-
XStream 1.1 released - Serialize Java objects to XML and back (30 messages)
- Posted by: Joe Walnes
- Posted on: January 15 2005 15:44 EST
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.htmlThreaded Messages (30)
- thanks for an excellent tool by peter lin on January 17 2005 07:50 EST
- XStream 1.1 released - Serialize Java objects to XML and back by Martin Crawford on January 17 2005 08:47 EST
- Can this tool generate java objects from an xsd? by kurt stam on January 17 2005 09:11 EST
- I might be wrong by peter lin on January 17 2005 09:17 EST
-
xstream is .... by Joe Fawzy on January 17 2005 09:52 EST
-
EVERYONE READ THIS TWICE by Tim Chadwick on January 17 2005 10:34 EST
-
EVERYONE READ THIS TWICE by kurt stam on January 17 2005 12:21 EST
-
EVERYONE READ THIS TWICE by Tim Chadwick on January 17 2005 03:22 EST
-
different from java.beans.Encoder? by Pankaj Tandon on January 17 2005 03:31 EST
-
different from java.beans.Encoder? by Cameron Purdy on January 17 2005 04:18 EST
-
different from java.beans.Encoder? by Nils Kilden-Pedersen on January 17 2005 08:20 EST
- different from java.beans.Encoder? by Cameron Purdy on January 17 2005 09:43 EST
-
different from java.beans.Encoder? by Pankaj Tandon on January 18 2005 04:28 EST
-
different from java.beans.Encoder? by Nils Kilden-Pedersen on January 19 2005 11:54 EST
- Problem with XMLEncoder encoding objects by Catherine Balajadia on August 18 2005 02:43 EDT
-
different from java.beans.Encoder? by Nils Kilden-Pedersen on January 19 2005 11:54 EST
-
different from java.beans.Encoder? by Nils Kilden-Pedersen on January 17 2005 08:20 EST
-
different from java.beans.Encoder? by Cameron Purdy on January 17 2005 04:18 EST
-
different from java.beans.Encoder? by Pankaj Tandon on January 17 2005 03:31 EST
-
EVERYONE READ THIS TWICE by Tim Chadwick on January 17 2005 03:22 EST
- RE: Everyone Read This Twice by Geoffrey Wiseman on January 20 2005 03:21 EST
-
EVERYONE READ THIS TWICE by kurt stam on January 17 2005 12:21 EST
-
EVERYONE READ THIS TWICE by Tim Chadwick on January 17 2005 10:34 EST
-
xstream is .... by Joe Fawzy on January 17 2005 09:52 EST
- I might be wrong by peter lin on January 17 2005 09:17 EST
- J# support? by Roger Voss on January 17 2005 12:51 EST
- you should be able to by peter lin on January 17 2005 12:55 EST
-
Performance Comparison by Jonathan Taylor on January 17 2005 01:56 EST
- informal benchmarks by peter lin on January 17 2005 02:08 EST
-
Performance Comparison by Jonathan Taylor on January 17 2005 01:56 EST
- J# support? by Bob Lee on January 17 2005 17:32 EST
- you should be able to by peter lin on January 17 2005 12:55 EST
- XStream 1.1 released - Serialize Java objects to XML and back by Shailendra Kumar on January 18 2005 00:56 EST
- XStream 1.1 released - Serialize Java objects to XML and back by Ganesh Ravindran on January 18 2005 23:35 EST
- HTML representation by Mark Ashworth on January 18 2005 09:14 EST
- multithreaded problems by Matt Giacomini on January 18 2005 13:08 EST
- multithreaded problems by Joe Walnes on January 19 2005 07:02 EST
- Tiger 5.0 Supported? by Peter Kasson on January 19 2005 21:21 EST
- CannotResolveClassException by Scott Ferguson on January 31 2005 09:42 EST
- Same problem upon deserialization by Kelly Vista on February 26 2005 21:23 EST
- com.thoughtworks.xstream.converters.ConversionException by Pham Van on July 09 2012 11:33 EDT
- Same problem upon deserialization by Kelly Vista on February 26 2005 21:23 EST
-
thanks for an excellent tool[ Go to top ]
- Posted by: peter lin
- Posted on: January 17 2005 07:50 EST
- in response to Joe Walnes
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 -
XStream 1.1 released - Serialize Java objects to XML and back[ Go to top ]
- Posted by: Martin Crawford
- Posted on: January 17 2005 08:47 EST
- in response to Joe Walnes
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! -
Can this tool generate java objects from an xsd?[ Go to top ]
- Posted by: kurt stam
- Posted on: January 17 2005 09:11 EST
- in response to Joe Walnes
Just wondering... Couldn't find it on their website. -
I might be wrong[ Go to top ]
- Posted by: peter lin
- Posted on: January 17 2005 09:17 EST
- in response to kurt stam
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 ....[ Go to top ]
- Posted by: Joe Fawzy
- Posted on: January 17 2005 09:52 EST
- in response to peter lin
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) -
EVERYONE READ THIS TWICE[ Go to top ]
- Posted by: Tim Chadwick
- Posted on: January 17 2005 10:34 EST
- in response to Joe Fawzy
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 -
EVERYONE READ THIS TWICE[ Go to top ]
- Posted by: kurt stam
- Posted on: January 17 2005 12:21 EST
- in response to Tim Chadwick
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 -
EVERYONE READ THIS TWICE[ Go to top ]
- Posted by: Tim Chadwick
- Posted on: January 17 2005 15:22 EST
- in response to kurt stam
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 -
different from java.beans.Encoder?[ Go to top ]
- Posted by: Pankaj Tandon
- Posted on: January 17 2005 15:31 EST
- in response to Tim Chadwick
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 -
different from java.beans.Encoder?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: January 17 2005 16:18 EST
- in response to Pankaj Tandon
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 -
different from java.beans.Encoder?[ Go to top ]
- Posted by: Nils Kilden-Pedersen
- Posted on: January 17 2005 20:20 EST
- in response to Cameron Purdy
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 -
different from java.beans.Encoder?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: January 17 2005 21:43 EST
- in response to Nils Kilden-Pedersen
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 -
different from java.beans.Encoder?[ Go to top ]
- Posted by: Pankaj Tandon
- Posted on: January 18 2005 16:28 EST
- in response to Nils Kilden-Pedersen
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
:) -
different from java.beans.Encoder?[ Go to top ]
- Posted by: Nils Kilden-Pedersen
- Posted on: January 19 2005 11:54 EST
- in response to Pankaj Tandon
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?PlainOldJavaObjectI 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 -
Problem with XMLEncoder encoding objects[ Go to top ]
- Posted by: Catherine Balajadia
- Posted on: August 18 2005 02:43 EDT
- in response to Nils Kilden-Pedersen
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 -
RE: Everyone Read This Twice[ Go to top ]
- Posted by: Geoffrey Wiseman
- Posted on: January 20 2005 15:21 EST
- in response to Tim Chadwick
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? -
J# support?[ Go to top ]
- Posted by: Roger Voss
- Posted on: January 17 2005 12:51 EST
- in response to Joe Walnes
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. -
you should be able to[ Go to top ]
- Posted by: peter lin
- Posted on: January 17 2005 12:55 EST
- in response to Roger Voss
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 -
Performance Comparison[ Go to top ]
- Posted by: Jonathan Taylor
- Posted on: January 17 2005 13:56 EST
- in response to peter lin
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? -
informal benchmarks[ Go to top ]
- Posted by: peter lin
- Posted on: January 17 2005 14:08 EST
- in response to Jonathan Taylor
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 -
J# support?[ Go to top ]
- Posted by: Bob Lee
- Posted on: January 17 2005 17:32 EST
- in response to Roger Voss
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 -
XStream 1.1 released - Serialize Java objects to XML and back[ Go to top ]
- Posted by: Shailendra Kumar
- Posted on: January 18 2005 00:56 EST
- in response to Joe Walnes
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 -
XStream 1.1 released - Serialize Java objects to XML and back[ Go to top ]
- Posted by: Ganesh Ravindran
- Posted on: January 18 2005 23:35 EST
- in response to Shailendra Kumar
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 -
HTML representation[ Go to top ]
- Posted by: Mark Ashworth
- Posted on: January 18 2005 09:14 EST
- in response to Joe Walnes
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 -
multithreaded problems[ Go to top ]
- Posted by: Matt Giacomini
- Posted on: January 18 2005 13:08 EST
- in response to Joe Walnes
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? -
multithreaded problems[ Go to top ]
- Posted by: Joe Walnes
- Posted on: January 19 2005 07:02 EST
- in response to Matt Giacomini
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. -
Tiger 5.0 Supported?[ Go to top ]
- Posted by: Peter Kasson
- Posted on: January 19 2005 21:21 EST
- in response to Joe Walnes
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 -
CannotResolveClassException[ Go to top ]
- Posted by: Scott Ferguson
- Posted on: January 31 2005 09:42 EST
- in response to Joe Walnes
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. -
Same problem upon deserialization[ Go to top ]
- Posted by: Kelly Vista
- Posted on: February 26 2005 21:23 EST
- in response to Scott Ferguson
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. -
com.thoughtworks.xstream.converters.ConversionException[ Go to top ]
- Posted by: Pham Van
- Posted on: July 09 2012 11:33 EDT
- in response to Kelly Vista
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).......