Java Serialization: Persist Your Objects

With serialization, you can serialize (persist) any Java object for future use or recreate it from an existing source.

When a Java application is executed, a large number of objects are created. Most of these objects are created and destroyed in the runtime. It would be convenient if Java saved these objects for future use or recreated them from an existing source and then used themeven when the application is re-run after it was stopped. The good news is Java does support this mechanism with the Java Serialization API.

Serialization is the process of saving an object's state to a persistence store and also rebuilding the object from the saved information when needed in the future. With Serialization, you can serialize (persist) any object that you don't need or that may have been used in some other application or may be used later.

Understanding the Java Serialization API

Any Java object can be a candidate for serialization; it simply needs to implement the Serializable interface. This interface is a marker interface with no default implementation. The interface is an indication to the Java runtime that the object is valid for persistence.

The method writeObject(...) of the ObjectOutputStream class makes the serialization transparent to the developer. You don't need to worry about creating the persistent file, reading the end-of-file, creating a new file, etc., thereby relieving you of a lot of additional effort.

As an example, here is a DataAndTimeObject class that can be serialized:

The class SerializeObject has an implementation that can serialize the object DataAndTimeObject. This implementation also takes an argument for the serialize object file name, ignoring whether or not the file name would be dateAndTime.ser. The writeObject(...) method of the ObjectOutputStream class facilitates the serialization process. As discussed previously, the I/O streams take care of the file-handling overhead.

Here is the code for creating the object from the file dateAndTime.ser.

The readObject(...) method of the ObjectInputStream class facilitates creating the object in the runtime from the serialized object.

Understanding Transient Keyword

The transient modifier is very handy in cases where you need to avoid serializing certain information from the object's state. Transient modifiers could be threads, database connections, sockets, I/O streams, etc. There is no point in serializing these objects, as their states could be indeterminable when they are recreated. It is also possible that the source for a database connection no longer exists.

Though using transient keywords effectively looks tough, it's fairly simple. You just need to associate the attribute with a transient keyword and the serialization API takes care of the rest. All attributes that are associated with the transient keyword will not be serialized when object serialization takes place.

Object Serializing with Your Own Protocol

Most Java applications are well served by their default serialization protocol, but developers still have a choice to customize the serialization protocol with their own. Java supports this is by implementing the Externalizable interface, which has two methods with the following signatures.

Here, you can adjust the implementation for serializing and de-serializing to meet your requirements. You could serialize the object and have other primitive data types with it as well. The de-serialization process is just the reverse of the serialization process. The most important aspect here is that the de-serialization implementation can be proprietary, which can be useful in addressing security concerns. You can ensure that the de-serialized object you have created is not tampered with by using hash codes, which you can maintain in a proprietary placeholder.

You can also serialize states of previously ignored objects, such as database connections, provided you are certain that the connection is available with the right set of parameters required to serialize the object. I do not advise this approach.

Here are a couple of other serialization advisories:

During de-serialization, it is never a good idea to create an instance of the object with values for its attributes. You need to always use the default constructor, which has no arguments. You can fill up values for all the object's attributes later when it is created.

Serialization has its own file I/O impact on application performance. Analyzing the procedure carefully reveals that the standard file I/O operations are performed during serialization and de-serialization, with the complications of file I/O hidden from the developer. Of course, if you used the Externalizable interface, this complication is still present.

Avoiding Serialization

In some cases, you should not allow the objects you expose to be serialized. This is easy to do as well. Just overwrite the methods for the Externalizable interface and provide no implementation to the writeExternal(...) and readExternal(...) methods. This will ensure that no one can serialize the object.

The requirement for avoiding serialization could be as simple as supporting the Singleton pattern or preventing confidential information from circulating as files. The objects that you expose could be used by others in their runtimes, but they could not use the data available in other applications that breach contract/security.

Not a New Technology

Serialization is not a new technology that developers will have to learn from scratch. It is an idea/concept that all you are exposed to in most of your applications when you use the I/O package. This is just an advanced form of that concept with most of the little hurdles of file I/O hidden. The most important takeaway here is that serialization can be customized to the algorithms that you need; thereby increasing the security of the serialized data.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.