Homemade vs. Java Serialization

Question

I have a certain POJO which needs to be persisted on a database, current design specifies its field as a single string column, and adding additional fields to the table is not a

Answer 1

How about the standard JavaBeans persistence mechanism:

java.beans.XMLEncoder
java.beans.XMLDecoder

These are able to create Java POJOs from XML (which have been persisted to XML). From memory, it looks (something) like...

<object class="java.util.HashMap">
    <void method="put">
        <string>Hello</string>
        <float>1</float>
    </void>
</object>

You have to provide PersistenceDelegate classes so that it knows how to persist user-defined classes. Assuming you don't remove any public methods, it is resilient to schema changes.

Answer 2

I'll second suggestion to use JAXB, or possibly XStream (former is faster, latter has more focus on object serialization part). Plus, I'll further suggest a decent JSON-based alternative, Jackson (http://jackson.codehaus.org/Tutorial), which can fully serializer/deserialize beans to JSON text to store in the column.

Oh and I absolutely agree in that do not use Java binary serialization under any circumstances for long-term data storage. Same goes for Protocol Buffers; both are too fragile for this purpose (they are better for data transfer between tigtly coupled systems).

Answer 3

Elliot Rusty Harold wrote up a nice argument against using Java Object serialization for the objects in his XOM library. The same principles apply to you. The built-in Java serialization is Java-specific, fragile, and slow, and so is best avoided.

You have roughly the right idea in using a String-based format. The problem, as you state, is that you're running into formatting/syntax problems with delimiters. The solution is to use a format that is already built to handle this. If this is a standardized format, then you can also potentially use other libraries/languages to manipulate it. Also, a string-based format means that you have a hope of understanding it just by eyeballing the data; binary formats remove that option.

XML and JSON are two great options here; they're standardized, text-based, flexible, readable, and have lots of library support. They'll also perform surprisingly well (sometimes even faster than Java serialization).

Answer 4

You can optimize the serialization by externalizing your object. That will give you complete control over how it is serialized and improve the performance of process. This is simple to do, as long as your POJO is simple (i.e. doesn't have references to other objects), otherwise you can easily break serialization.

tutorial here

EDIT: Not implying this is the preferred approach, but you are very limited in your options if ti is performance critical and you can only use a string column in the table.

Answer 5

You need to consider versioning in your solution. Data incompatibility is a problem you will experience with any solution that involves the use of a binary serialization of the Object. How do you load an older row of data into a newer version of the object?

So, the solutions above which involve serializing to a name/value pairs is the approach you probably want to use.

One solution is to include a version number as one of field values. As new fields are added, modified or removed then the version can be modified.

When deserializing the data, you can have different deserialization handlers for each version which can be used to convert data from one version to another.

Answer 6

Consider putting the data in a Properties object and use its load()/store() serialization. That's a text-based technique so it's still readable in the database:

public String getFieldsAsString() {
  Properties data = new Properties();
  data.setProperty( "foo", this.getFoo() );
  data.setProperty( "bar", this.getBar() );
  ...
  ByteArrayOutputStream out = new ByteArrayOutputStream();
  data.store( out, "" );
  return new String( out.toByteArray(), "8859-1" );   //store() always uses this encoding
}

To load from string, do similar using a new Properties object and load() the data.

This is better than Java serialization because it's very readable and compact.

If you need support for different data types (i.e. not just String), use BeanUtils to convert each field to and from a string representation.