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.