This post originated from an RSS feed registered with Agile Buzz
by Joe Walnes.
Original Post: XStream roadmap: What do YOU want to see?
Feed Title: Joe's New Jelly
Feed URL: http://joe.truemesh.com/blog/index.rdf
Feed Description: The musings of a ThoughtWorker obsessed with Agile, XP, maintainability, Java, .NET, Ruby and OpenSource. Mmm'kay?
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.
Previous Topic
