Added by Jörg Schaible, last edited by Jörg Schaible on Nov 15, 2006  (view change)

Labels

 
(None)

XStream 2.0

The next major version of XStream will be 2.0. For this release we are planning to turn the current design upside down, keep the parts that have been proved of value and change those elements, that are currently limiting future development and new features. Therefore code compatibility is not our basic goal for the next release and we will rename the currently package name to allow coexistance of old XStream 1.x releases with the ones of 2.x. Additionally we will make usage of new Java features and drop all parts that are currently necessary due to limits in older JDK versions.

Architecture

A general overview of the individual layers and components of XStream 2.0:

  • Object Model: Model for Java objects and their internal represantation. Includes functionality of current mappers influencing the internal model.
  • [Transforming Layer]: Marshalling of the internal object model into a stream of DOM-like events and vice versa.
  • [Converters]: Helper classes to transform the content of an object as Strings into such events and vice versa.
  • [I/O Layer]: Readers acting on those events and writers creating them from an arbitrary data source.
  • [Facades]: Different facades hiding the complexity of the framework for special purposes.

Implementation

Discussion of implementation details we should consider and respect. And they should be kept somewhere to allow other users become more easily familiar with principles and internals.

  • [Generics]: Usage of JDK 5 generics. Where are they useful?
  • [Configuration]: Best approach to prepare the facade(s).
  • [Upgrade]: Strategy support for upgrades.
  • [Patterns]: Explicit usage of software patterns for the different parts and layers.

Testing

XStream 2.0 supports a lot of XML parsers, is supposed to run on multiple JDK versions >= 5.0 and has different catch-all converters (reflection-based, JavaBeans). Data formats should be compatible between different releases and JDKs. We need a better approach to ensure this.

  • Unit tests for the general functionality
  • Test suites for the same functionality with different backends (we have some of those in XStream 1.x)
  • Compatibility tests for the data format between XStream releases
  • Compatibility tests for the data format between runtimes
  • Benchmarking to detect the impact of changes