• See Storing data: Initial ideas page for reasons for choice of approach.
• It seemed sensible to split the job into two parts. First worked out how to encode the object to a String and to decode from it. Then once this was coded/tested it was simple to use this to write to/read from a file.

• Using XStream is really easy:

  • download Stable version 1.4.8 Binary distribution
  • add xstream-1.4.8.jar and xmlpull-1.1.3.1.jar to the Java Build Path in eclipse.
  • follow the two minute tutorial and the job is pretty much done.

• Although it is described as a simple library to serialize objects to XML and back again it does not require the underlying classes to be Serializable. So it is able to make a sensible, structured human readable XML file without any modifications of the underlying classes.

• XStream uses reflection and its use of constructors is a bit of a mystery to me. Because I have singleton objects to issue id's it was necessary to register id's after the read in to make sure that they are not reissued.

• The structure of XML document produced is interesting: contacts.xml (Should display in most browsers) The way that objects are cross-referenced using reference= and an array field is really clever. For instance this defines a past meeting with 4 participants:

<contactmanager.PastMeetingImpl>
<id>25</id>
<date><time>-5181580800000</time><timezone>Europe/London</timezone></date>
<contacts>
<contactmanager.ContactImpl reference="../../../../contacts/contactmanager.ContactImpl"/>
<contactmanager.ContactImpl reference="../../../../contacts/contactmanager.ContactImpl[2]"/>
<contactmanager.ContactImpl reference="../../../../contacts/contactmanager.ContactImpl[3]"/>
</contacts>
<notes>Battle of Trafalgar</notes>
</contactmanager.PastMeetingImpl>

• Thought Serialization direct to a file might not meet the specification of a "text" file.
• Serialization to string was more difficult to get to work.
• Used the Vogel Object Serialization Tutorial and stackoverflow page as a start.
• It was necessary to change the underlying classes to use Serializable.
• The initial implementation using the procedure proposed on many web sites could encode but failed to decode TODO must add comments to that page for others to avoid the trap?
• An alternative method that uses base64 encoding worked. Java8 now has its own
  base64 encoding so this simplified things.
• More class changes were necessary after run time exceptions, overall much more complex to use than XSTREAM.
• The file produced are text files and contain the information but are not of much interest to look at contacts.txt, other than to note that A is repeated many times (presumably because of repeated 0 in original) so file should compress a bit (see below)
• It is important to alter serialVersionUID after any class alterations to produce an reasonable exception message on reading a file written from the previous version.

• size contacts.xml and contacts.txt have same information but the XML is 2.1 KB compared to 7.4 KB for Serialization. Compression with gzip the reduces size to 0.5 KB and 3.5 KB. So XML produces smaller files.
• speed Here Serialization is faster. JUnit FileSaveRetrieveTest is parameterized to run the same tests first for XML and then for serialization eclipse report 0.86 seconds and 0.11 seconds.
• feedback on errors Here XStream produces really good feedback
• robustness XStream generally copes with minor alterations in the Objects well. Serialization does not.
• human readability no comparison here.
• These results support the information from XStream web page Features section.

Both Serialisation and XStream are easy to use and would reduce both development time and maintenance for a real world contact manager. XStream would be much best solution as it would mean there was some chance of debugging user problems and it would be possible to parse old versions of the files much more easily.