email article printer friendly get the code more resources

XML Persistence Pays Off
XMLEncoder provides a method of serialization that is simple to use and valuable for persisting Java objects
by Kei G. Gauthier

August 13, 2004

I worked with the JavaBeans XML Persistence API for more than a year before I realized that I could use it to serialize any object. When its default mechanisms did the trick, the API produced compact, version-resilient archives. When they failed, however, I thought that extending the API wasn't worth the trouble. This misconception was unfortunate because it kept me from using the full potential of XML persistence. With just a little knowledge, I could easily have customized the API to handle any class that I wanted to throw at it. In my defense, lack of documentation about its advanced use contributed to my confusion about the degree of difficulty involved in extending the API.

Nevertheless, I was forced to go beyond the default mechanisms of XML persistence when a project required me to serialize visual components from the Eclipse Standard Widgets Toolkit (SWT). As a GUI that competes with Awt and Swing, SWT diverges from Sun's standards in many ways. Eclipse uses native code to implement its visual components. Each of its widgets must refer back to a parent at the time of construction and, therefore, lacks a null-argument constructor. In addition, Eclipse widgets do not get garbage collected automatically. Instead, they must be disposed specifically when they are no longer necessary.

I took the persistence of these classes as a challenge and figured that if I could serialize them, I could save anything. With no other alternative, I resorted to studying the source code for the persistence classes and the examples of custom serialization implementations contained in java.beans.MetaData.java. It took a while, but the more I learned about the API, the more I liked it. My opinion changed from considering it as little more than an incomplete, bug-ridden kludge to appreciating its high quality. After I understood how things worked, it took very little time to write custom code to save the SWT classes. As an added benefit, I found that visual components archived under one operating system could be restored under a different one, even though native code was used to implement the GUI.

Custom Persistence
The JavaBeans package already correctly serializes most of the object types included in the Java Foundation Classes (JFC). Problems arise when you try to use the persistence strategy to serialize one of the few JFC types still subject to an unresolved bug or when you apply it to objects outside the JFC.

You may wonder how you can develop code to persist an object that the API designers themselves were unable to handle. I suggest that you can do it quite easily. Since this serialization model saves objects by recording the steps needed to recreate them, all you have to do is store representations of the same statements you used to construct your objects in the first place. You have an easier job than the programmers at Sun. Not knowing how classes would be used, they had to develop methods to serialize every conceivable permutation of every JFC type. When persisting your own objects, you are not charged with such a difficult task. You know exactly how you constructed your classes and can therefore easily write code to save them by duplicating this process.