Java Serialization to XML 
download > support > buy

uses
- features
- benefits
technology
accuracy

customers
case studies

pricing
about us
Technology
JSX works for all possible objects, both POJOs (plain old java objects) and Serializable objects, for Java 1.2, 1.3, 1.4, 1.5, 1.6 and 1.7. There are no constructor requirements, no getter/setter requirements and no need for any interfaces to be implemented nor classes extended.

JSX handles all POJOs

  • multidimensional arrays
  • cyclic references - an object that refers to itself, or an object that eventually refers to it are correctly reproduced
  • final fields - JSX sets final fields
  • constructor-independent - JSX creates objects without requiring a no-argument constructor
  • shadowed fields - superclass and subclass fields with the same name are distinguished
  • private fields - non-public fields are read and set correctly
  • beans - JSX does not require get/set methods, and so is not restricted to java beans
  • polymorphism - when a field contains a subclass of its type, JSX records and recreates an object of that subclass.

    JSX handles all Serializable objects
    Many standard Java classes - and third party classes - implement the Serializable interface, and may rely on the sophisticated JOS specification to define their own "serial format". JSX complies with this standard for both Serializable and Externalizable interfaces, so these serial formats are also represented in XML. Reusing their serial format is much more convenient (and technically elegant) than requiring a special delegate or surrogate to be written whenever a new Serializable class is encountered. Reusing the existing serial format is the key to JSX being truly dynamic.

    Some XML-object mappers (eg XMLEncoder, Betwixt, XStream, Skaringa) require special code (variously known as delegates, converters or adapters) to handle many standard Java classes, such as BigDecimal, Date and TreeMap. Unfortunately, this approach fails at runtime if an appropriate converter is not available. Ironically, most problematic classes already incorporate code for their own serialization, using Java's built-in binary serialization. Rather than reinvent the wheel, JSX simply reuses this existing code and converts its output to XML (as a sequence primitive and object values, marked- up by type). Note: Classes do not need to implement "Serializable"; yet code for serialization is reused, when available.

    JSX works for all classes, with no requirement for complex delegates to write for current, future or third-party classes. This solution is automatic, simple and more reliable than designing, writing, testing and then maintaining converters that do the same thing.

    For evidence, please see this demonstration of reliability.

    More about serialization and encapsulation
    Directly reading and writing the private state of an object violates encapsulation. Fortunately, the Java Object Serialization (JOS) standard defines hooks into each object, enabling it to read and write its own state, without violating encapsulation.

    Initializing transient fields A specific case is transient fields, which are not written or read by serialization. Instead, they are initialized by code within the JOS hooks.

    Back-compatibility Another case is fields that were previously defined in a class, which can be read and written as "virtual fields" using the JOS hooks, to ensure back-compatibility. This is needed even for minor releases of Java (eg between 1.4.0_01 and 1.4.1_02) where the internal state may evolve.

    Inconsistent state If these hooks are not used, then deserialized objects will not be initialized correctly, silently leaving them in an inconsistent state. This problem is especially insidious because no exception will be thrown when they are created, as there is no validation of the objects. It may only become apparent later on, when the inconsistent state causes the object to fail in arbitrary ways, at unexpected times, apparently unconnected with serialization.

    Ad hoc converters An ad hoc alternative to using the JOS standard is whenever a class such as the above is encountered (and you realize it), then to write an explicit converter to handle it. Ensuring capture of the complete state of the object requires an in-depth understanding of the implementation of each class. A misunderstanding of it will leave deserialized object in an inconsitent state, again causing failure in arbitrary ways at unexpected times.

    JSX is the only XML serializer to use the standard JOS hooks.