Java Object Serialization: Risks and benefits and the Stale Code Bug Pattern

Serialization lets a programmer convert a Java object to a string of bytes in a JVM independent form that can be stored or transmitted over a network and recreate the object when needed. The same technique in python is called Pickling. Since the serialised object is stored in a JVM independent form it can be serialised on one platform and recreated on another.

This is a useful technique for saving time and space but has security risks in terms of protecting sensitive data, transferring objects between applications and may exhibit the stale code bug pattern.

What is serialisation and why do it

Serialisation lets you write a java object as a series of bytes either to persistent storage or across a network. Enterprise Java beans (EJB), a technology that now seems to be defunct, transparently serialised objects in order to transfer them between a server and a client.

In Java, the object is written to an object output stream and read from an object input stream. 

An object may take a long time to create but rarely need to be created. In this case serialisation can save time, memory (if the object is only recreated on demand) and bandwidth.

If all an objects fields are serialisable serialising and reconstructing an object is one way to create a deep clone of that object.

Note that some automatic code generation Frameworks may not produce serialisable code and may thus be unsuitable, as they stand for applications that need serialisation.

There is a straightforward guide to implementing serialisation, on Tutorialspoint

Confidential data

Serialised objects may contain sensitive data, for example credit card numbers. The risks involved can be minimised by marking sensitive variables as transient, for transient fields are not included in the serialised object.

Note that transient is not the same as volatile, though the two are sometimes confused.

Any fields of an object that are also objects should be examined for sensitive data. A field that is not serialisable will result in a NonSerializableException.

Since a serialised object is merely a string of bytes the string should be encrypted before sending it over an unprotected transmission channel. This is less important if a secure transmission protocol is used but should be done if a high level of security is needed. It is also a good idea to encrypt the serialised object while it is stored.

The Stale Code Bug Pattern

The Stale Code Bug Pattern arises if the code you are running is not the code you think you are running. This can happen when using the wrong version of a jar file and can also happen with serialised objects.

Serialisation produces a frozen snapshot of a Java object. If the functionality of the object's class changes but the snapshot is not updated the behaviour of the object recreated from the snapshot is unpredictable and the problem is often hard to identify, leading to deleted expletives from developers who, till the penny drops, wonder why the debugger shows the control flow entering unexpected territory.

A more obvious problem can arise in development when, perhaps as a result of poor codebase management leading to violations of the DRY rule or copy-paste coding there are multiple functionally identical copies of a class in different packages. The decision to standardise on one package is obvious and sensible but recreated objects from snapshots of the discarded versions of the class give rise to a ClassCastException.

This problem can be resolved, if the snapshot is not encrypted, by opening (a copy of) the serialised object in a text editor, locating the class name and changing it to the fully qualified name of the class to be used. Other metadata may have to be changed depending on the application.

The Wrap

Serialisation is a powerful and useful technique with risks and dangers, not all of which are apparent before development starts, though an architect should be aware of these and communicate them to developers who may not have used this technique before.

The design phase of a project should identify the classes and fields to be serialised and identify procedures for preventing the Stale Code Bug Pattern from causing problems in production, and tests to identify the subtler versions of this bug pattern.