XStream roadmap: What do YOU want to see?
I’m assessing where the next version of XStream should go. There are three major chunks of work I’d like to tackle (described below), however I can only take on one at a time and need to prioritize.
What do you want to see? Leave your comments on my blog.
1. Full support for the Java serialization specification.
Current situation: XStream uses reflection to access an objects fields and convert them to and from XML.
Problem: While this works well with most custom objects, 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.
Solution: The default Converter in XStream could be enhanced to support these features.
Outcome: XStream should be able to serialize any object that standard Java serialization can, without any modifications.
2. Improved JVM support.
Current situation: XStream uses reflection to instantiate objects when deserializing. Using plain reflection, this requires each object to have a default constructor, which XStream will call. An ‘enhanced-mode’ is also supported that uses JVM specific calls to construct objects without ever invoking a constructor, guaranteeing no side-effects.
Problem: Currently the ‘enhanced-mode’ is only available if using the Sun 1.4 JVM or later.
Solution: Enhance the enhanced mode to support more popular JVMs, including Sun 1.3, IBM 1.4, and JRockit.
Outcome: More users can use XStream without having to make intrusive modifications to their classes.
3. Configurable mappings.
Current situation: XStream was originally designed as a tool for transparent serialization of objects (specifically for persistence or to send across the wire in messaging systems). As such, the goal was to allow XStream to figure out what the XML should look like on the fly, without forcing the mappings to be defined for each class.
Problem: An unforseen popular usage of XStream is for assembling objects from XML configuration files. However, because XStream has been designed to just figure out the XML on the fly, it does not allow users to (easily) specify their own XML structure.
Solution: To add more simple to use ‘tweaks’ to the generated XML. For example, to allow attributes to be used in some elements, alias elements based on where they appear or remove redundant tags to make the XML easier to understand.
Outcome: More flexibility for the resulting XML, without forcing users to write custom converters.
Joe Walnes 
+1 for sun jdk 1.3 support for extended mode
This may be specific to my case but another useful feature would be to add a config switch where one can force writing of the class attribute for each property on a class. This is helpful when using XStream to serialize objects to rich client applications that use a language other than Java that does not have good reflection capabilities (Javascript, ActionScript) – basically some way to specify types like in SOAP. I found XStream to be a great solution for serializing objects between Java and ActionScript (Flash).
I’m a big big fan of option 3. I’d also like to be able to specify context-based aliasing. For example, if I have an object with two collections in it. In one case I want the elements of the collection to be written as ‘element’, and in the other to be written as ‘component’.
Another useful feature that isn’t on this list is the ability to easily tweak the customisation. For example, I have an arbitrary business object, and I want the serializer to ignore fields that start with the name ‘temp’. It’d be handy if there were a base class to extend for this sort of usage, rather than having to write a custom converter that does everything.
One thing cool about XStream is it’s simplicity. Comparing to other tools that convert between POJO and XML, the others require more lines of configuration and setup, either as additional lines of code or other configuration files.
It’s simple because there’s little “customisation” necessary.
I would like whatever features XStream add, to maintain this simplicity.
I’m thinking of using XStream for short-term persistance as well as for persisting configuration. One of the questions that has come up is how to handle versioning. That is, if I change the property name in the object, I don’t necessarily want the XML element/attribute name to change.
Joe,
I’d give -1 for Configurable mappings. The primary characteristic of XStream is its simplicty, and one thing that makes it possible is no mappings. Introducing mappings is opening a Pandora’s box – as other XML libraries show, there’s no end to the complexity of mapping functionality. It’s not just poor APIs … there are intrinsic issues with object-xml mappings.
Currently, XStream handles the typical case of no fixed format well. By introducing mappings, XStream risks becoming one of many libraries that handles mappings, but not especially complex ones. I realise it would still handle the no-mapping situation well, but the mappings would dilute the simplicity. Also, any future enhancements might be hampered by having to maintain the mapping support. The no-mapping scenario is sufficiently common to warrant a dedicated library such as XStream.
Personally, I’d prefer to see configurable mappings as a separate project, possibly built on XStream. This way, it would be possible to evolve much more complex mapping styles if need be, without impacting on the minimalist XStream core.
Joe,
We use XStream on my current project and here’s some customisations we require, some of which you mentioned (and how we have implemented them) :
1. Remove prefix from fields for element name (i.e. underscore). Implemented with a custom converter.
2. Some fields need to be attributes, not elements (implemented as a bit of a hack at the moment using a naming convention on the field name and changing the XStream source.)
3. Specified Element Ordering. Not sure how to implement this yet, but want to avoid custom mappers for each class if possible. We’re thinking about some sort of annotations.
4. Managing Empty Tags (we cannot have them). We currently manage this with preProcessing our object model before serailization to manually null elements we consider empty (e.g. empty strings, objects containing only empty strings.)
Cheers,
Darren.
I agree with Michael M. What I really like about XStream is that it’s one of the few really useful tools out there where you don’t have to anything to get it working for you.
Configurable Mappings would be good but you’ll never be able to please the diverse requirement of this without detracting simplicity from XStream. So a separate probject would be a good way to go IMO.
+1 for configurable mappings.
freeJSX already does 1 and 2 (in fact, implemented them in 2001, so that now they are fully developed and debugged).
There’s little point in reinventing the wheel, and cloning another project? (unless I guess as an act of aggression).
freeJSX
PS: The freeJSX project is at http://www.csse.monash.edu.au/~bren/JSX/
FreeJSX does the mappings, but to the exception of no-configurability. You cant alias, you can’t create custom converters… plus it is gpl which is commercial averse.
+1 for 1 and 2
We all know where freejsx is, we just dont use it!
How about XStream for C# – this would allow use of XStream as an across the wire packetizer, and pass between java .net. Less messing around and simpler than the WS infastructure overhead.
Hi,
I would like to know the diff between Castor XML and XStream.
The 3rd point-Configurable mappings when included would enable XStream and Castor XML to have provide the same functionality ie. XML->Object and vice versa.
Is there any other major difference?
Pl let me know.
Thanks
Gopi