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)

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.

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?

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?

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.

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).

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?

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.

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#.

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.

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.

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?

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.

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.

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.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.