Serialization

Why this matters

• A missing serialVersionUID is the classic cause of a deployment that fails to read yesterday's cached data.
• Deserialising untrusted bytes is one of the most exploited vulnerability classes in Java history, and knowing why is a genuine security skill.
• Even though JSON has replaced it for most purposes, Java serialization still appears in session replication, caches and older RMI-based systems.

The basic mechanism

Implement the marker interface Serializable and the JVM handles the rest.

public class Session implements Serializable {
    private static final long serialVersionUID = 1L;

    private final String userId;
    private final Instant createdAt;
    private transient String authToken;     // excluded from the bytes
    private static String appName;          // static: never serialized

    public Session(String userId, Instant createdAt, String authToken) {
        this.userId = userId;
        this.createdAt = createdAt;
        this.authToken = authToken;
    }
}

// Writing
try (ObjectOutputStream out = new ObjectOutputStream(Files.newOutputStream(path))) {
    out.writeObject(session);
}

// Reading
try (ObjectInputStream in = new ObjectInputStream(Files.newInputStream(path))) {
    Session restored = (Session) in.readObject();
    System.out.println(restored.authToken);     // null — it was transient
}

serialVersionUID

This long is the class's structural fingerprint. It is written into the stream and checked on read.

private static final long serialVersionUID = 1L;

If you omit it the compiler computes one from the class's fields, methods and modifiers. That sounds convenient and is a trap: adding a single field changes the computed value, and every previously written stream becomes unreadable with InvalidClassException.

Controlling the process

Two hooks let you customise without replacing the whole mechanism.

public class Account implements Serializable {
    private static final long serialVersionUID = 1L;

    private String id;
    private transient char[] password;          // never written in plain form

    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();                // the normal non-transient fields
        out.writeObject(encrypt(password));      // plus our own handling
    }

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        in.defaultReadObject();
        this.password = decrypt((byte[]) in.readObject());
        validate();                              // the validation the constructor would have done
    }

    private void validate() {
        if (id == null || id.isBlank()) {
            throw new InvalidObjectException("id is required");
        }
    }
}

These methods are private and the JVM finds them reflectively. readObject is the right place to restore transient state and to run the validation that the skipped constructor would have performed.

A stricter option for small immutable classes is readResolve, which lets you replace the deserialised instance entirely:

private Object readResolve() {
    return new Account(id, password);     // route through the real constructor
}

This also preserves the singleton property, which plain deserialisation otherwise breaks by producing a second instance.

Externalizable

Externalizable hands you complete control and complete responsibility.

The security problem

readObject can construct arbitrary objects and run code paths during deserialisation. If an attacker controls the bytes, they can assemble a chain of objects whose deserialisation side effects execute commands — a deserialisation gadget chain. Several widely used libraries have shipped classes usable in such chains.

// Allow only your own classes, with bounded depth, and reject everything else
ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
        "com.prepzone.model.*;java.base/*;!*");
ObjectInputStream in = new ObjectInputStream(source);
in.setObjectInputFilter(filter);

Common misreadings

• "transient fields are encrypted." They are simply absent, and return as null or 0.
• "static fields are serialized." They belong to the class and are never written.
• "Deserialisation calls the constructor." It does not, which is why validation must be repeated in readObject.
• "serialVersionUID is optional." Technically yes, practically no. Omitting it means the compiler changes your compatibility contract whenever the class is edited.
• "Serialization is a good deep-copy tool." It works but is slow, needs everything Serializable, and silently drops transient fields.
• "Serialization preserves singletons." It creates a second instance unless you add readResolve.