Java Serialization with Non Serializable Parts

1. Introduction

In this tutorial, we explore how to use Java serialization with types that aren’t designed for it. We’ll take a look at a few different techniques to handle this and see the benefits of each.

2. What Is Java Serialization?

Java serialization is a built-in mechanism in Java that lets us serialize our objects. We can convert objects to a stream of bytes, and then later convert those bytes back into the original object. This includes full type information so we get the correct original types back out again, even if we’re not in the same JVM. All we need is the correct class definitions on the classpath.

We can serialize our objects using the java.io.ObjectOutputStream construct. This wraps another OutputStream and lets us write any Java type to it:

ObjectOutputStream oos = new ObjectOutputStream(outputStream);
oos.writeObject(user);

In the other direction, we use a java.io.ObjectInputStream to read our previously written objects:

ObjectInputStream ois = new ObjectInputStream(bais);
Object readObject = ois.readObject();
User readUser = (User) readObject;

The problem is that this only works on types that implement java.io.Serializable, and requires that all fields of these objects also implement java.io.Serializable. The JVM throws a NotSerializableException whenever you attempt to write an object that isn’t serializable.. This can significantly restrict the cases where we can use this if we’re not careful. However, there are some ways we can manage this limitation.

3. Transient Fields

One way that we can manage this issue is by the use of transient fields. Transient fields are fields that don’t form part of an object’s persistent state. This means that writing out our object doesn’t serialize these fields. As such, they don’t need to implement Serializable, and the system will still be able to serialize the parent object.

We can apply this to fields whose values we derive from other state in the object. For example, to cache an expensive calculation:

class User implements Serializable {
    private String name;
    private String profilePath;
    private transient Path profile;

    public User(String name, String profilePath) {
        this.name = name;
        this.profilePath = profilePath;
    }

    public Path getProfile() {
        if (this.profile == null) {
            this.profile = FileSystems.getDefault().getPath(profilePath);
        }

        return this.profile;
    }
}

In this case, the profile field represents the location on the filesystem of the actual profile picture. We compute it the first time we need it and store it from then on. But since Path instances aren’t serializable, we need to handle this ourselves if we ever serialize our User instance.

We can manage this by marking the field as transient. This means that serialization skips the field when the object is written out. It also means that, when we deserialize our object, the field is left with its default value. This is null in the case of object fields, or a suitable default in the case of primitive fields:

ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(user);

ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bais);
Object read = ois.readObject();
User readUser = (User) read;
// readUser.profile is always null at this point

This should be fine since, by definition, transient fields are intended to be used in this way. In this case, we’ll automatically populate the field again the next time we call the getProfile() method.

3.1. Populating with readResolve()

While we can often leave transient fields with their default values, in some cases, we need to populate them explicitly. Java offers the readResolve() method as a way to handle this.

If the readResolve() method is defined on our object, it will be called immediately after our instance is deserialized. The return value from this is then the object that’s returned from our deserialization. This lets us perform any actions we need to correctly initialize our object, such as populating fields marked as transient:

class User implements Serializable {
    private String name;
    private String profilePath;
    private transient Path profile;

    public User(String name, String profilePath) {
        this.name = name;
        this.profilePath = profilePath;
        this.profile = FileSystems.getDefault().getPath(this.profilePath);
    }

    public Object readResolve() {
        this.profile = FileSystems.getDefault().getPath(this.profilePath);
        return this;
    }
}

Here we’re populating our transient field in the constructor, which ensures that we always provide a value for it. However, because it’s transient, it will be unpopulated after deserialization. We use the readResolve() method to populate it correctly after we deserialize the object.

If we don’t want to modify the existing object, we can instead return a different instance from the readResolve() method:

public Object readResolve() {
    return new User(this.name, this.profilePath);
}

The only requirement here is that the returned object must be compatible with the expected type. A ClassCastException will be thrown if it’s not.

4. Custom Serialization With readObject() and writeObject()

Sometimes we may need to fully serialize our objects, even though not all of the fields are serializable. We can’t always rely on marking the fields as transient and hoping the resulting object will work without them having a value. For example, if our User class doesn’t store the profile path as a separate string:

class User implements Serializable {
    private String name;
    private Path profile;

    public User(String name, String profilePath) {
        this.name = name;
        this.profile = FileSystems.getDefault().getPath(profilePath);
    }
}

Java offers us the ability to completely control serialization using the writeObject() and readObject() methods.

We serialize the object exactly as we want by implementing the writeObject() method. The ObjectOutputStream automatically calls it while serializing the object to write its state:

private void writeObject(ObjectOutputStream out) throws IOException {
    out.writeObject(name);
    out.writeObject(profile.toString());
}

Here we’re writing the name field as-is, but we’re writing out a custom form of the profile field that’s safe to serialize.

The opposite of this is the readObject() method. This is responsible for deserializing the state of the object from a provided ObjectInputStream:

private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
    String nameTemp = (String) in.readObject();
    String profilePathTemp = (String) in.readObject();

    this.name = nameTemp;
    this.profile = FileSystems.getDefault().getPath(profilePathTemp);
}

This has to be the exact opposite of the writeObject() for things to work correctly. Here we’re reading the name field directly, but we’re reading the String that we wrote for the profile field and using it to construct the Path object again.

4.1. Wrapper Classes

In some cases, we need to serialize a class that isn’t serializable and also that we don’t control the source code of. For example, one that comes from a dependency that we’re using. If we can’t change the class itself, we’re unable to use any of the above techniques for serializing it.

In this case, one option we have is to write a new class that we do control. This class can then act as a wrapper around the class we want to serialize. Because this new class is in our control, we can change it however we need – for example, by writing writeObject() and readObject() methods:

static class UserWrapper implements Serializable {
    private User user;

    public UserWrapper(User user) {
        this.user = user;
    }

    private void writeObject(ObjectOutputStream out) throws IOException {
        out.writeObject(user.name);
        out.writeObject(user.profile.toString());
    }

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        String nameTemp = (String) in.readObject();
        String profilePathTemp = (String) in.readObject();

        this.user = new User(nameTemp, profilePathTemp);
    }
}

In this case, we’re not changing the User class at all. Instead, we’ve written a new UserWrapper class that exists purely for serialization, and we’ve added the same writeObject() and readObject() methods to this that we wrote before.

We still wouldn’t be able to serialize a User object directly, but we can now serialize a UserWrapper object instead:

ObjectOutputStream oos = new ObjectOutputStream(outputStream);
oos.writeObject(new UserWrapper(user));

Conversely, when we’re reading we need to know to read the wrapper class and then extract the inner class from it:

ObjectInputStream ois = new ObjectInputStream(bais);
Object read = ois.readObject();
UserWrapper wrapper = (UserWrapper) read;
User readUser = wrapper.user;

Here we’ve got back to our original User object even though it’s not possible to serialize it directly.

5. Summary

In this article, we took a deeper look at Java serialization and explored several ways to serialize objects that the JVM doesn’t consider serializable. Next time you need to use Java serialization, why not try some of these out.

As usual, all of the examples from this article are available over on GitHub.