Version 1.0 of XStream, a simple open source library to serialize objects to XML and back again has been released.

XStream is designed to be fast, places no constraints on the objects being serialized, is easy to use, produces very concise XML and requires no mapping configuration.

Specific features:

  Ease of use. A high level facade is supplied that simplifies common use cases.
  No mappings required. Custom objects can be serialized without need for specifying mappings.
  Performance. Speed and low memory footprint are a crucial part of the design, making it suitable for large object graphs or systems with high message throughput.
  Clean XML. No information is duplicated that can be obtained via reflection. This results in XML that is easier to read for humans and more compact than native Java serialization.
  Requires no modifications to objects. Serializes internal fields, including private and final. Supports non-public and inner classes. Classes are not required to have default constructor.
  Full object graph support. Duplicate references encountered in the object-model will be maintained. Supports circular references.
  Integrates with other XML APIs. By implementing an interface, XStream can serialize directly to/from any tree structure (not just XML).
  Customizable conversion stategies. Strategies can be registered allowing customization of how particular types are represented as XML.
  Error messages. When an exception occurs due to malformed XML, detailed diagnostics are provided to help isolate and fix the problem.

Read more at http://xstream.codehaus.org/

fyi

Ronald Bourret maintains a list of XML data binding tools and libraries:

http://www.rpbourret.com/xml/XMLDataBinding.htm

One of the coolest xml binding technologies around today.

What´s the advantage of this framework over Castor?

//Roger

Castor is extremely slow. Some timings of Castor vs. the Apache implementation of JAXB that I have measured:

Document size Castor Jaxme
300 bytes 220ms 63ms
3K 425ms 140ms
30K 2.1s 266ms
300K 14.2s 1.0s

Castor's performance degraded severely for large documents.

Stan

What´s the advantage of this framework over Castor?//Roger

Castor is for XML to Java binding (you start with XML) while XStream is for Java to XML binding (you start with Java).

I only worked with XML-to-Java before and I know that it is a very diffcult task. XML Schema allows one to specify extremely complex XML document structures that are very hard to bind to Java. I tried using Castor to bind some of our customers' XML Schemas but at that time, Castor's XML-to-Java binding was not updated for the latest XML Schema spec.

John Davies, of c24, had a good presentation on a similar topic at the recent TSS Symposium. Last I checked, I couldn't find his slides, but I'd expect to see them soon (if they're not already up.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Hi Cameron,
    Thanks for the plug. I asked Neven today about the slides, seems he's doing them as we type, I've got them if anyone wants them.

I've not tried XStream yet but you can be sure I won't be going to bed until I have. It's not unexpected to see a lot of projects in this space, it's why we avoided XML in the first place and stuck to what we know best SWIFT, FIX, OMGEO, CREST, etc. etc.

Anyway, there is no reason why a project like this couldn't do what we do, codehaus is normally a good source of reasonable quality projects. More comments once I've checked it out.

I wouldn't however expect them to be able to support the customers to the level that we do, not just in XML but also in non-XML standards (see list above).

So, off to hit IntelliJ and write some code, watch this space!

-John Davies-
CTO of the World's premier XML (or non-XML) to Java application "Integration Objects"

OK, I've had a look. It just looks to me like another Betwixt (from apache's commons project). It looks a little better in some ways but it is no way near what we do (heart back its usual rate). It doesn't seem to need the binding between the Java and XML which should make it easier to use but that in itself would reduce control and could even introduce problems that are not easy to fix (due to the lack of control).

I'm going to try it, it could be useful, I found Betwixt a complete waste of time, to much effort for little gain but this looks rather good for small java beans. I wonder how this could work with Axis, i.e. WSDL, SOAP and the likes.

We come at this from the other direction, we take XML Schema/DTDs etc. and then generate the Java to match the Schema (including validation etc.). We can not take Java and generate XML and I have absolutely no intention of going there. We get a lot of our XML business from companies (banks etc.) that are having serious problems with XML performance, FpML, SwapsWire and the likes, we generate then nice Java code to speed things up (by orders of magnitude).

-John Davies- (strangely sober for a Friday night, still drying off after Vegas)

Looks like very good stuff! Does anyone know if there is anything comparable available for .Net (and is open source?).

I need a java-to-xml-to-java object serializer and a dotnet-to-xml-to-dotnet object serializer.. You do the math what it is for.. ;)

This seems to fit the bill for the first part at least.. Good job!

.NET includes some very good xml serialization tools in the Xml.Serialization namespace. Normally, this requires marking up classes with attributes. I don't like using attributes unless I have to or want to, so I investigated it further. Via XmlAttributeOverrides, you can build up a collection of what would be attributes on your classes without marking your classes up. That way you can declare your mapping b/w xml and object without making your objects dependent on xml markup attributes.

The nice thing about their libraries is that they make it very easy to serialize/deserialize once you have a set of attribute overrides, and you also have built in support for validating against (and generating) schemas.

Hi Wille!

I've tryed to reach you on your e-mailadress at Networkavalanche, but it doesn't exits anymore. So now I try to contact you this way. Could you contact me at: joris at vdros dot nl

It's because of your homepage, I have a question....

Hope to hear from you soon! Greetings, Joris van der Ros from The Netherlands

This is an excellent piece of software! It's super easy to use and does exactly what you want from it.

Especially the Sun 1.4 JVM enhanced mode is impressive: Any java objects -> XML -> java objects without problems...

Very nice work indeed!

i like XStream because it is small and very fast, but I do not like the way Xstream creates XML, because it makes it too big, like

<person>
  <name>blah</blah>
  <age>21</age>
  <lastname>blahblah</lastname>
</person>

there should be a way to create it like ,

<person name="blah" age="21" lastname="blahblah" />

they mention about "Customizable conversion stategies" but there is no documentation about it.

Apparently someone at Codehaus didn't get the memo that Groovy killed XML...

very nice- one small point- the faq on the website mentions "pure java" and "enhanced" mode, however, it fails to mention how to configure xstream into one or the other mode... (it seemed to me to just automagically pump into enhanced mode when running via jdk1.4.2_03?)

the longer xml format is fine... rather than the shorter format using attributes... the longer format really shouldn't be an issue because xml wasn't really designed to be a storage-efficient format... if one needs storage efficiency then run it thru gzip!

well done!

the longer format really shouldn't be an issue because xml wasn't really designed to be a storage-efficient format... if one needs storage efficiency then run it thru gzip!well done!

well, i believe attributes format is more readable and more suitable especially for configuration and persistence. storage efficiency is only a bonus. mapping primitive values and Strings as attributes does not hurt the implementation.

well, i believe attributes format is more readable and more suitable especially for configuration and persistence. storage efficiency is only a bonus. mapping primitive values and Strings as attributes does not hurt the implementation.

sure- perhaps, ideally, xstream would have a configurable option to spew out xml in either format (i.e., favoring 'attributes' vs favoring 'elements').

I actually find the elements format (the way xstream does it) easier to read! I guess it is personal preference (e.g., personally I think ant files are more difficult to read than they need to be and would be made easier to read if ant favored elements instead of attributes)... (or better yet, accepted both ways!!!)

sometimes the contributors to this portal are so
smart they are stupid:


how anyone could suggest that:

<person firstname="john" lastname="doe" address="151 Main Street"/>


is more readable than:

<person>
  <firstname>john</firstname>
  <lastname>doe</lastname>
  <address>151 Main Street</address>
</person>

is quite simply beyond me...


if you want to litter your xml syntax with attributes, by all means,
go with it, everyone has the power to write badly read source
code, why should XML syntax be any different?

and the argument that "attribute rich" xml is somehow shorter, or smaller
in byte length, is, well, not even worth addressing...

Finally,

XML, was and still is, designed to bring structure and contextual meaning
to raw data, period. It does a really good job of that, if used correctly,
and scripting languages do not fulfill that goal, and never will.

well, not so. i used and i am using XStream right now. i like it and keep using it. My suggestion matters if you have big list objects which is very common.
Suppose you have a list of Person object, which contains "name", "lastName" and "age" properties. And another object carrying a list containing 30 of person objects. When you covert it to XML you will have *rap load of unnecessary tags with maybe 150 lines of text. If you put string objects and primitives as attributes, the shape of the xml to me is much shorter and readable with 30 lines of text. i had a situation creating 1000 such objects and size of the xml started to matter after a while.
After all i just made a small suggestion telling adding an option to make primitive and String ojects as attributes. I do not say add another xml format to determine the shape of the xml. Maybe irrelevant but, i have never seen an XML format so far each object property is represented as a tag. maybe those guys were "stupid" too. right?

<people>
  <person>
    <name>aaa</name>
    <lastname>bbb</lastname>
    <age>11</age>
  <person>
  <person>
    <name>ccc</name>
    <lastname>..</lastname>
    <age>..</age>
  </person>
  ...
</people>

versus

<people>
  <person name="aaa" middlename="bbb" age="11" />
  <person name="bbb" middlename="ccc" age="22" />
<people>

i agree that in your example the xml using attributes is indeed easier to read, and will save bytes...

but i still maintain that overuse of attributes in general tends to create very messy xml syntax, have a look at any typical application server config file, JBoss is particularly nasty...

also, attributes, if not used very carefully, can tend to obscure the structure of the data, and this works against one of the original and most powerful design motivations for xml...

anyway, i'll leave it at that, and not burden this thread any further...

cheers
Peter

From http://www.w3schools.com/xml/xml_attributes.asp

Here are some of the problems using attributes:

* attributes cannot contain multiple values (child elements can)
* attributes are not easily expandable (for future changes)
* attributes cannot describe structures (child elements can)
* attributes are more difficult to manipulate by program code
* attribute values are not easy to test against a Document Type Definition (DTD) - which is used to define the legal elements of an XML document
* If you use attributes as containers for data, you end up with documents that are difficult to read and maintain. Try to use elements to describe data. Use attributes only to provide information that is not relevant to the data.

Don't end up like this ( if you think this looks like XML, you have not understood the point):

<note day="12" month="11" year="2002"
to="Tove" from="Jani" heading="Reminder"
body="Don't forget me this weekend!">
</note>

I agree wholeheartedly. If size matters, don't use xml.

//ras

It's worth pointing out one more limitation of attributes: Elements can have attributes; attributes can't.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

well, i guess whole point of XStream was to make XML serialization faster, not making a fully functional XML parser and encoder. of course size does matter in this case. Besides, i proposed that making an option for only "primitives and Strings" as attributes automatically, that is why your points on weakneses of using attributes are somewhat irrelevant for XStream serialization. As i told again i needed to send 1000 objects in a list containing primitive values as XML, and result of the XStream was horrendous by size and by readability..
And if you say dont use XML if size matters, then why should people make stg like XStream anyway?

And if you say dont use XML if size matters, then why should people make stg like XStream anyway?

Good question :) I guess I was a bit off topic.

I just happen to be an XML dogmatic, a sort of religious fanatic.. I have the following dogma:
* if you don't need xml, don't use xml
* if you use xml, use it properly

Properly, to me, means:
* use schemas (or dtd's)
* follow some best practices like "don't use attributes as data containers" ;)

And this sometimes means, that the Java classes should be derived from the xml schema, not the other way round. So maybe I have a too xml-centric view on this.

If you totally control the xml and the data and don't need to share the xml data with applications not under your control, then this kind of attribute-data xml might be an ok choice for serialization.

//ras

From http://www.w3schools.com/xml/xml_attributes.asp

Here are some of the problems using attributes: * attributes cannot contain multiple values (child elements can) * attributes are not easily expandable (for future changes) * attributes cannot describe structures (child elements can) * attributes are more difficult to manipulate by program code * attribute values are not easy to test against a Document Type Definition (DTD) - which is used to define the legal elements of an XML document * If you use attributes as containers for data, you end up with documents that are difficult to read and maintain. Try to use elements to describe data. Use attributes only to provide information that is not relevant to the data.Don't end up like this ( if you think this looks like XML, you have not understood the point):

<note day="12" month="11" year="2002"to="Tove" from="Jani" heading="Reminder" body="Don't forget me this weekend!"></note>

I agree wholeheartedly. If size matters, don't use xml.//ras

I used to agree with all of this. However, I now look at it differently. I think if you only need to hold a single, unstructured value then attributes are fine. In the future, if you need to hold multiple values or change to a structured value then you'll have to modify the code that uses or creates the XML anyway. That problem isn't avoided by choosing to use elements now. That addresses the first three bullets.

The fourth bullet is just plain not true. In fact, when using DOM attributes are easier to work with than elements because you don't have to iterate through child nodes looking for those that are text nodes and concatenate them together.

The fifth bullet only matters if you haven't made the transition from DTDs to XML Schema yet.

The sixth bullet is a matter of preference. I find attributes easier to read. They are less noisy.

sometimes the contributors to this portal are so smart they are stupid:how anyone could suggest that:<person firstname="john" lastname="doe" address="151 Main Street"/>is more readable than:<person>  <firstname>john</firstname>  <lastname>doe</lastname>  <address>151 Main Street</address></person>is quite simply beyond me...

As for me, human-readable XML is not a discussion point when we are talking about SERIALIZATION library. If you would like to read XML, you'd better to think twice ;-). The most serious reason to store values as atributes is that we might want to keep some extra bytes from sending via internet. In other words we do not want to have a BIG XML from a small javabean just b/c it's easy to read it. BUT if you are seriously support to use the library like this you may want to check how it works with specific data that requires character escaping or something like that... That is why storing properties as nested elements much more reasonable, b/c we may wrap it into CDATA section then. So my answer is :<person><firstname><![CDATA[john]]></firstname> <lastname><![CDATA[doe</lastname>]]> <address><![CDATA[151 Main Street]]></address></person>.

the longer format really shouldn't be an issue because xml wasn't really designed to be a storage-efficient format... if one needs storage efficiency then run it thru gzip!well done!

well, i believe attributes format is more readable and more suitable especially for configuration and persistence. storage efficiency is only a bonus. mapping primitive values and Strings as attributes does not hurt the implementation.

It is a matter of preference. I would run it through XSL to create HTML tables. I think that would be more readable than the raw XML text.

very nice- one small point- the faq on the website mentions "pure java" and "enhanced" mode, however, it fails to mention how to configure xstream into one or the other mode... (it seemed to me to just automagically pump into enhanced mode when running via jdk1.4.2_03?)the longer xml format is fine...

If you're using the XStream facade, you can specify the reflection provider in the constructor:

XStream xstream = new XStream(new PureJavaReflectionProvider());

'XStream' and 'C25 Integration Objects' are two very different products with different uses.

XStream is designed for configurationless serialization. This makes it painless to serialize any type of objects, without the need for mappings. Ideal for things like persistence, configuration and over-the-wire transports. However, because there are no mappings, you have little control of how the serialized object is represented.

Integration Objects is a much more sophisticated product suite allowing mappings of objects to virtually any format - databinding. Ideal for, well, integrating objects :). As products in this category go, IO is certainly a very impressive set of tools. However with flexibility, you also need to take the time to create and maintain your mappings.

If you don't have constraints on how your XML and what something that 'just sorts it out' for you, XStream is a good fit. If you need precise control of how your objects are represented and are happy to spend time defining mappings, use Integration Objects.

If you don't have constraints on how your XML and what something that 'just sorts it out' for you, XStream is a good fit. If you need precise control of how your objects are represented and are happy to spend time defining mappings, use Integration Objects.

And if you combine XStream with XSLT through SAX API, you get full control over how your XML appears, and the XML-Java binding. We are using XStream this way to process SOAP messages based on complex XML schemas. So XSLT acts as your mapping definition, and it is much more powerful than plain declarative "binding" mappings, since it is a full-blown templating language.

XStream is an excellent library and definitely has a future in XML integration techologies.

I've now had some time to play with XStream and it's pretty good. I can see a lot of areas where I might use it in the future, it's definitely a big improvement on Apache's Betwixt IMOHO.

This comment though encourages me to make a point though...

And if you combine XStream with XSLT through SAX API, you get full control over how your XML appears, and the XML-Java binding. We are using XStream this way to process SOAP messages based on complex XML schemas. So XSLT acts as your mapping definition, and it is much more powerful than plain declarative "binding" mappings, since it is a full-blown templating language. XStream is an excellent library and definitely has a future in XML integration techologies.

There is a big big difference between XML data and XML documents and I get the impression the two are being mixed up here (in the quote above). This is the source of a lot of problems with SOAP and other XML based EAI. SOAP is used mainly for data, XSL (XSLT and XSL-FO) is really designed for transforming documents not data. OK, you can mix them but you can also write code in JSPs and HTML in Servlets but it doesn't make it right. If you are going to base your integration on XST then you are going to quickly run into problems when things get complex. If you have simply XML/SOAP then fine, it'll work but be careful, look at what the technologies were designed for. XML's origins are HTML/GML/SGML etc. i.e. documents not data, XSL is for document "Style" not data transformation.

If you've found a solution that works though, great, stick with it, just bare the above in mind if you start planning for the future.

Regards,

-John Davies-
CTO, C24
London, UK

I understand the comment about using XSLT for style transformations but are you really saying that since XML came from HTML, SGML, etc. that it is not well suited for data representation. I thought that is why XML came about, because you cannot really represent data in HTML, SGML, etc. XML really gave us the ability to describe data, and that documents ARE data, but that the converse it not necessarily true.

There is a big big difference between XML data and XML documents and I get the impression the two are being mixed up here (in the quote above). This is the source of a lot of problems with SOAP and other XML based EAI. SOAP is used mainly for data, XSL (XSLT and XSL-FO) is really designed for transforming documents not data. OK, you can mix them but you can also write code in JSPs and HTML in Servlets but it doesn't make it right. If you are going to base your integration on XST then you are going to quickly run into problems when things get complex. If you have simply XML/SOAP then fine, it'll work but be careful, look at what the technologies were designed for. XML's origins are HTML/GML/SGML etc. i.e. documents not data, XSL is for document "Style" not data transformation.

That's probably why WSDL allows to choose between RPC style (data-centric?) and Document-literal style (document-centric?) operations.

IMO, RPC style interfaces tend to get out of control fast when things get complex:

1. It does not impose crucial insulation layer between external/exposed and internal views of data, and
2. It tends to take Java object model too far outside into XML world, but forgets to arm you with necessary tools like structural query (XPath), or rule-based processing.

On the other hand, Document style in combination with XSL and XStream (the missing link!) allows you to stay in XML world while transforming external data/document into internal Java model and back, and that's where the power of XSL templates and XPath shine.

Regards,

Leon

How does XStream compare with XMLEncoder and XMLDecoder (which are part of the Sun J2SDK API since 1.4) ?

One of the advantages seems to be that the info obtainable through reflection is not kept in the xml file.... but wouldnt that cause a overhead while deserializing ?

Another one is that XMLEncoder and XMLDecoder are limited to serialization of objects adhering to java beans specs(if i remember correctly) while XStream isnt.

so i guess i better start using XStream.

references:
http://java.sun.com/products/jfc/tsc/articles/persistence4/
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLEncoder.html

Java Serialization to XML (JSX) already does this: no mappings required; requires no modifications to objects; supports circular references and does not require "Serializable". In addition, JSX works for Java 1.2 and 1.3, as well as for Java 1.4 and for other versions of Java, such as IBM's J9.

JSX1 is free (open source) and available from: http://www.csse.monash.edu.au/~bren/JSX/

JSX has been tested and proven by many users over three years, and this real-world code exercise has resulted in a highly reliable product. Many corporations have bought licenses for the non-open version (JSX2: http://www.jsx.org).


JSX also has a deep technical benefit:
XStream and XMLEncoder require special code ("converters" or "delegates") to handle many standard Java classes (such as BigDecimal and TreeMap). If a converter is not available for a particular class, serialization will fail at runtime. And yet, all these classes already incorporate code for serializing themselves with Java's built-in serialization. The solution? JSX reuses this existing code for XML. Thus, there are no complex converters or delegates to write, and current, future and third-party classes are handled automatically and transparently. This is simple and effective and, we believe, a more elegant solution.

NB: JSX does not actually require the "Serializable" interface or existing code; but where present, the existing code will be reused. If desired, the serial form of a class can be customized with the standard serialization mechanism, or replaced with a "memento".

BTW: JSX1 represents primitives and strings with attributes, which is preferred by many (but not all!) users over a whole tag for each one.


Transparent XML-Java mapping is a very exciting technology, with many powerful applications (see http://jsx.org). It is great to finally see another entrant to this space, which will hopefully spread word to a larger audience. Welcome, XStream!


Cheers,
Brendan Macmillan

Simple.Elegant.kewllllllllllllllll.
Thats what we want it.
Keep it up tigers!!!

I tried serializing an object and I'm getting this exception:

Invalid final field java.util.SimpleTimeZone.monthLength

I looked into the code and the exception is thrown in PureJavaReflectionProvider.java:

line 70:
protected void validateFieldAccess(Field field) {
        if (Modifier.isFinal(field.getModifiers())) {
            throw new ObjectAccessException("Invalid final field "
                    + field.getDeclaringClass().getName() + "." + field.getName());
        }
    }

Does this mean that objects that have final fields won't work?

If anyone is interested it looks like the pure java mode doesn't support final fields: http://xstream.codehaus.org/faq.html. So much for using this with Websphere.

If you tell me which JDK you are using, we can try to provide enhanced mode operation in a future release.

Thanks
-Joe

JSX already serializes java objects to XML and back, including setting final fields in Java 1.2, 1.3, 1.4 and 1.5.

http://www.jsx.org

Or there's an open source version at:
http://www.csse.monash.edu.au/~bren/JSX/


Or, a google search on "jsx" will find them both. :-)

Going to the link on your page to jsx.org shows that you have to pay for the latest version (2.2.0). I don't know what happened to their open source versions but the only one I could find was 1.0.7.4. Is their latest version also released as open source?

private String serialize(Object o)
{
    return new XStream(new DomDriver()).toXML(o);
}

private Object deserialize(String serialize)
{
  return new XStream(new DomDriver()).fromXML(serialize);
}

When i have the object after deserialize the date attributtes are zero, the fields its a timestamp, its serialize only the nano part and not the time part

JSX2 is not open source.

However, JSX1 (the old version 1.0.7.4, GPL open source) works very well, and has been tested and big-fixed extensively. The reason for no updates is simply no bug reports. However, there was a bug report recently, so there should be a new release soon (version 1.0.7.5, nothing dramatic).

The new (commercial) version JSX2 (now 2.2.2) has superior performance, and has a redesigned XML format which is more verbose than JSX1, because more comprehensive and logical. The XML format is fixed (ie a static schema) so it is simpler to access with other tools (XQuery, XSLT etc).

XStream seems like an early version of JSX1.

XStream looks really great and being supported by codehaus is sure to give it great exposure.

It sure seems like there are many, many players in this space. I wrote a simple framework 3 years ago to read XML configuration files and released it open source a year ago. It's a very simple framework and only really gets extended when a need arises in my 'day job'. It too supports the concept of custom serializers/parsers for different object types and will serialize to either all element XML or a mix of elements/attributes (you can decide on an object property basis if it gets written as an element or attribute). It's based on the getter/setter paradigm and if you want to take a peek you can find it at: http://www.bifrost.org/xmlio

I wonder how many of these frameworks started as something to solve a specific inhouse problem and got cleaned up and released almost as an afterthought...

I just glanced over the XStream API, so please correct
me if I overlooked something, but I find it rather limiting
that you can only seralize to/from textual XML (String/Reader).
I would like to see the posibility to use in-memory object-oriented
XML (e.g. DOM-tree) as input and output.

AFAIK the Java 1.4 XMLDecoder/Encoder has the same limitation,
but Castor is more flexible.

Regards,

Stefan

I just glanced over the XStream API, so please correctme if I overlooked something, but I find it rather limitingthat you can only seralize to/from textual XML (String/Reader). I would like to see the posibility to use in-memory object-orientedXML (e.g. DOM-tree) as input and output.AFAIK the Java 1.4 XMLDecoder/Encoder has the same limitation,but Castor is more flexible.Regards,Stefan

You are not limited to this at all. The toXML/fromXML methods are only for convenience.

XStream can read/write to any tree-style API such as DOM or even a custom syntax. To do so, you need to provide it an implementation of HierarchicalStreamReader/HierarchicalStreamWriter and call XStream.marshal()/unmarshal() instead of XStream.toXML()/fromXML().

http://xstream.codehaus.org/javadoc/com/thoughtworks/xstream/io/HierarchicalStreamReader.html
http://xstream.codehaus.org/javadoc/com/thoughtworks/xstream/io/HierarchicalStreamWriter.html

There are a few implementations of these (based on user demand) and it's easy to create your own.

For example:

org.dom4j.Document document = // an existing doc
xstream.marshal(myObject), new Dom4JWriter(document)); // serialize
Object newObject = xstream.unmarshal(new Dom4JReader(document)); // deserialize

I just downloaded Breeze Factor. Has anybody used this before?

Thanks

-Pete

I'd avoid Breeze Factor. Use something else (JAXP, JAXB, XNI, DOM, SAX, whatever.) Breeze Factor's products aren't particularly bad -- however, whoever is behind the company seems to disappear for months and even years at a time. Which ultimately leaves customers hanging with potentially critical support issues, and no recourse but to switch products. The person behind Breeze is a talented programmer, but he runs a very poor business.

I downloaded yesterday and tried it. From my initial impression using it and stress testing a simple webapp on tomcat, it's pretty nice. I was able to use JMeter to stress test an app with 1-16 threads. I wrote a simple servlet to use XStream that reads in 25Kb of XML and outputs 75Kb of data. In between it does some processing. With 16 threads the CPU usage average 70-75%. Unlike DOM, Castor and JAXB, XStream doesn't eat up 100% of the CPU with 10 concurrent threads. I used a laptop with 1Gb of RAM and 1.4ghz Pentium M CPU. Parsing 25Kb of XML with 16 threads took an average of 4-5ms, which is pretty darn good.

I spend an hour benchmarking XStream. Thought others might find this interesting.
10000 iterations
------------------
1K - .7ms
3K - 1.2ms
7K - 2.8ms
10K - 4.3ms
13K - 5.8ms
16K - 6.4ms

I spend an hour benchmarking XStream. Thought others might find this interesting.10000 iterations------------------1K - .7ms3K - 1.2ms7K - 2.8ms10K - 4.3ms13K - 5.8ms16K - 6.4ms

That the average time it took to parse the document once. for the total time multipley by 10K.

What exactly is enhanced mode? A Google search doesn't seem to reveal much. Is there some Sun documentation on it?

A critical bug in XStream:
http://jira.codehaus.org/browse/XSTR-92

However, JSX does handle this www.jsx.org. The xstream architecture wasn't designed with
this issue in mind, and it would have to be changed fundamentally to accommodate it. Unfortunately, implementing this correctly would also
require a much more complex XML format (and so losing the attractive simplicity
it has now). In fact, it would need to look like JSX's format, which is
more verbose, but actually works.

An older version of JSX is available as open source, which is pretty
much complete, but not as fast nor as polished as the commerical version.
http://www.csse.monash.edu.au/~bren/JSX/

There are at least three well-known solutions to the XML/Object-binding problem on the market:

- XStream (from Codehouse)
- JSX (not developed further)
- JAXB (Java API for XML Binding)

The question is: Which is best?

Since JSX is not developed anymore, we will remove this from the list.

For our company, performance is a big issue, so I have compared XStream and JAXB with "JUnitPerf" (a performance-measuring extension to JUnit).

The test was simple:

(A) Parse a given XML String back into an object tree.
(B) Produce a XML String from an object tree.

Using 200 iterations (to get comparable results), and running several test runs, we got this mean values:

XStream: Parse 704ms Produce 221ms
JAXB: Parse 340ms Produce 173ms

So it clearly shows that JAXB (Sun RI) outperforms XStream.
If performance is your problem, try using JAXB instead of XStream.

BTW, JAXB has some more benefits. E. g. it creats Java Classes from XSD, while you have to write them on your own with XStream. On the other hand, using JAXB is more complex than using XStrem. So you have a clear tradeoff between ease of use to performance.

Hope this helps anybody.

Have Fun
Markus KARG (markus dot karg at gmx dot net)

There are at least three well-known solutions to the XML/Object-binding problem on the market:- XStream (from Codehouse)- JSX (not developed further)- JAXB (Java API for XML Binding)The question is: Which is best?Since JSX is not developed anymore, we will remove this from the list.For our company, performance is a big issue, so I have compared XStream and JAXB with "JUnitPerf" (a performance-measuring extension to JUnit).The test was simple:(A) Parse a given XML String back into an object tree.(B) Produce a XML String from an object tree.Using 200 iterations (to get comparable results), and running several test runs, we got this mean values:XStream: Parse 704ms Produce 221msJAXB: Parse 340ms Produce 173msSo it clearly shows that JAXB (Sun RI) outperforms XStream.If performance is your problem, try using JAXB instead of XStream.BTW, JAXB has some more benefits. E. g. it creats Java Classes from XSD, while you have to write them on your own with XStream. On the other hand, using JAXB is more complex than using XStrem. So you have a clear tradeoff between ease of use to performance.Hope this helps anybody.Have FunMarkus KARG (markus dot karg at gmx dot net)

Maybe you should read the FAQ:

Q: Is XStream a data binding tool?
A: No. It is a serialization tool.

Naturally, a binding tool, where the structure is known, will perform faster than generic serialization tool, working on an arbitrary structure.