XML Serialization Library

SourceForge Logo


The main idea that motivated this work was to be able to represent a java object in an XML formatted file. Basically, Java serialization allows you to turn any object into a ".ser" file, which can then be stored, or sent through the network... The problem with this approach is that the serialized object is not human readable and thus cannot be edited by hand or even read. We would like to produce something that is human readable and editable. This can then be used for configuration files for example.

The format of the file

We want the format of the file to be as straightforward as possible. Thus there is going to be a specific DTD for each kind of object (each class). Let's take an example:
public class MyTest
  private int myIntField;
  private double myDoubleField;
  private java.util.Date myDateField;

will be represented by

with the following DTD:
<!ELEMENT myDateField (#PCDATA)>
<!ELEMENT myDoubleField (#PCDATA)>
<!ELEMENT MyTest (myIntField, myDoubleField, myDateField)>
<!ELEMENT myIntField (#PCDATA)>

NB: I will explain how to actually represent a "Date" object by a simple string (this is called customization).

How to use it

The package contains 2 main classes:
There is a third class that can be used as a tool to generate the correct DTD: ClassToDtd. You invoke it like this: 'java org.xeril.xml.ClassToDtd xxxxx' where xxxx is the name of the class (including the package information). Please note that you can 'tweak' the DTD by hand afterwards (for example, adding '?' if a parameter is optional).


You can customize the way the XML file will look like: you need to create a new simple class for this customization (it is inspired by the Bean/BeanInfo pattern). You have to create a class that complies to the 2 following requirements:
  1. the class must implement the XmlInfo interface.
  2. the name of the class is derived from the name of the class you want to customize by appending XmlInfo (ex: if you want to customize test.MyTest then you have to name the class test.MyTestXmlInfo). An extension to this, in order not to pollute the global namespace with this kind of class, is to define an XmlInfo class which is nested within the original class (thus the name of that new class would be test.MyTest$XmlInfo)
The best solution is probably to inherit from the SimpleXmlInfo class which implements the XmlInfo interface and provides some convenient methods.


The XmlInfo interface holds two methods.
  1. getXmlName(): returns the xml tag name of this class (if you don't provide it then the class name will be taken instead).
  2. getXmlMapDescriptors(): returns an array of XmlMapDescriptor objects. Each one of this object allows you to specify what you want to do with a field (you don't have to provide one for each field... because if not defined then default value will be taken, for example the name of the tag will be the name of the field).


A XmlMapDescriptor allows you to customize one field:


XmlMapper is another interface that maps an object to a string representation and vice-versa. This is extremely powerfull and can be extended at will. This package provides 2 'standard' mapper classes and it is easy to write your own:


Here is an example that tries to cover all the aspects of the package:

Constraints, restrictions and future developments

Dependencies and requirements

License and Copyright

This library is Copyright (C) 2000, 2001 Yan Pujante. It is subject to the Mozilla Public License. You can find a text version here.


You can download a tarball (.tar.gz) which contains the library (a jar file) and the source. Click here to download (22Kb).


The source of this project can be extracted from CVS on sourceforge.net at cvs.xeril.sourceforge.net:/cvsroot/xeril and the directory name is XeriL
Yan Pujante
Last modified: Sat Nov 10 19:07:07 PST 2001