Browse Prior Art Database

Serialization by code generation Disclosure Number: IPCOM000180178D
Original Publication Date: 2009-Mar-05
Included in the Prior Art Database: 2009-Mar-05
Document File: 1 page(s) / 39K

Publishing Venue



This article discusses a means of storing and retrieving complex data structures to a storage device to maintain data where a process has been recycled. The data is usually written to some storable form, saved to disk, then a deserialization program reads, and usually parses and converts the data back into its memory based form. This system puts much of the load of the process on deserialization. However, is cases where the data is stored once and read many times such as a caching system, the ideal solution would be to have the load placed on serialization, and a quicker deserialization technique. This article suggest using code generation to achieve this end.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 96% of the total text.

Page 1 of 1

Serialization by code generation

This article proposes a system using code generation such that the serialization consists of storing - instead of a serialized form of the objects - a class with a well known method - this method directly creates the object again from the original field values.

    The serialization starts with a data structure with some values in it. A bytecode framework such as ASM is used to create a jar* file, and a class is generated with a method called "run" - taking no parameters, or taking some context parameter such as where to attach the newly created data structure.

    The run method is generated by first emitting bytecodes to create a new data structure, then walking the old data structure and emiting code to recreate the value within each field.The finished run method and class are stored in the jar.

The process of deserialization of the data is now a question of retrieving the

ar file, loading the class and calling its 'run' method.

    In this particular embodiment, and custom class loader is used, such that the generated jar files are automatically incorporated into the classpath of the JVM, and so the new classes are located, but there could equally be a single jar file in which all generated classes are stored and this could be added to the normal application classloaders classpath.
*Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other coun...