personal void readObject(ObjectInputStream in)  throws IOException, ClassNotFoundException {
    in.defaultReadObject();
    this.rating = calculateScore();
}

Why order issues in customized serialization logic

When writing customized serialization logic, the order during which values are written should precisely match the order during which they’re learn:

personal void writeObject(ObjectOutputStream out) throws IOException {
    out.defaultWriteObject();
    out.writeInt(42);
    out.writeUTF("Duke");
    out.writeLong(1_000_000L);
}
personal void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
    in.defaultReadObject();
    int degree = in.readInt();
    String title = in.readUTF();
    lengthy rating = in.readLong();
}

As a result of the stream just isn’t keyed by discipline title, every learn name merely consumes the following worth in sequence. If readUTF had been referred to as earlier than readInt, the stream would try and interpret the bytes of an integer as a UTF string, leading to corrupted information or a deserialization failure. This is among the primary causes customized serialization must be used sparingly. A helpful psychological mannequin is to think about serialization as a tape recorder: Deserialization should replay the tape in precisely the order it was recorded.

Why serialization is dangerous

Serialization is fragile when lessons change. Even small modifications could make beforehand saved information unreadable.

Deserializing untrusted information is especially harmful. Deserialization can set off sudden code paths on attacker‑managed object graphs, and this has been the supply of actual‑world safety vulnerabilities.

For these causes, Java serialization must be used solely in managed environments.

When serialization is smart

Java serialization is appropriate just for a slender set of use circumstances the place class variations and belief boundaries are tightly managed.

Rule of thumb: If the info should survive class evolution, cross belief boundaries, or be consumed by non‑Java programs, desire JSON or a schema‑based mostly format over Java serialization.

Superior serialization strategies

The mechanisms we’ve coated thus far deal with most sensible situations, however Java serialization has just a few further instruments for fixing issues that default serialization can’t.

Preserving singletons with readResolve

Deserialization creates a brand new object. For lessons that implement a single occasion, this breaks the assure silently:

public class GameConfig implements Serializable {

    personal static ultimate lengthy serialVersionUID = 1L;
    personal static ultimate GameConfig INSTANCE = new GameConfig();

    personal GameConfig() {}

    public static GameConfig getInstance() {
        return INSTANCE;
    }

    personal Object readResolve() throws ObjectStreamException {
        return INSTANCE;
    }
}

With out readResolve, deserializing a GameConfig would produce a second occasion, and any id verify utilizing == would fail. The tactic intercepts the deserialized object and substitutes the canonical one. The deserialized copy is discarded.

Substituting objects with writeReplace

Whereas readResolve controls what comes out of deserialization, writeReplace controls what goes into serialization. A category can outline this methodology to substitute a distinct object earlier than any bytes are written.

The 2 strategies are sometimes used collectively to implement a serialization proxy. One class represents the thing’s runtime kind, whereas one other represents its serialized kind.

On this instance,ChallengerWriteReplace performs the function of the “actual” object, whereas ChallengerProxy represents its serialized kind:

public class ChallengerProxy implements Serializable {

    personal static ultimate lengthy serialVersionUID = 1L;

    personal ultimate lengthy id;
    personal ultimate String title;

    public ChallengerProxy(lengthy id, String title) {
        this.id = id;
        this.title = title;
    }

    personal Object readResolve() throws ObjectStreamException {
        return new ChallengerWriteReplace(id, title);
    }
}

class ChallengerWriteReplace implements Serializable {

    personal static ultimate lengthy serialVersionUID = 1L;

    personal lengthy id;
    personal String title;

    public ChallengerWriteReplace(lengthy id, String title) {
        this.id = id;
        this.title = title;
    }

    personal Object writeReplace() throws ObjectStreamException {
        return new ChallengerProxy(id, title);
    }
}

When a ChallengerWriteReplace occasion is serialized, its writeReplace methodology substitutes it with a light-weight ChallengerProxy. The proxy is the one object that’s really written to the byte stream.

Throughout deserialization, the proxy’s readResolve methodology reconstructs a brand new ChallengerWriteReplace occasion, and the proxy itself is discarded. The applying by no means observes the proxy object instantly.

This system retains the serialized kind decoupled from the interior construction of ChallengerWriteReplace. So long as the proxy stays secure, the primary class can evolve freely with out breaking beforehand serialized information. It additionally gives a managed level the place invariants may be enforced throughout reconstruction.

Filtering deserialized lessons with ObjectInputFilter

I’ve defined why deserializing untrusted information is harmful. Launched in Java 9, the ObjectInputFilter API offers purposes a technique to limit which lessons are allowed throughout deserialization:

ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
        "com.instance.mannequin.*;!*"
);

strive (ObjectInputStream in = new ObjectInputStream(new FileInputStream("information.ser"))) {
    in.setObjectInputFilter(filter); // have to be set earlier than readObject()
    Object obj = in.readObject();
}

This filter permits solely lessons beneath com.instance.mannequin and rejects all the things else. The sample syntax helps allowlisting by package deal, in addition to setting limits on array sizes, object graph depth, and complete object depend.

Java 9 made it potential to set a process-wide filter by way of ObjectInputFilter.Config.setSerialFilter or the jdk.serialFilter system property, making certain that no ObjectInputStream can be left unprotected by default. Java 17 prolonged this additional by introducing filter factories (ObjectInputFilter.Config.setSerialFilterFactory), which permit context‑particular filters to be utilized per stream quite than counting on a single international coverage. In case your utility deserializes information that crosses a belief boundary, an enter filter just isn’t elective; it’s the minimal viable protection.

Java data and serialization

Java data can implement Serializable, however they behave in a different way from atypical lessons in a single vital approach: Throughout deserialization, the report’s canonical constructor known as. This implies any validation logic within the constructor runs on deserialized information, which is a big security benefit:

public report ChallengerRecord(Lengthy id, String title) implements Serializable {
    public ChallengerRecord {
        if (id == null || title == null) {
            throw new IllegalArgumentException(
                    "id and title should not be null");
        }
    }
}

With a conventional Serializable class, a corrupted or malicious stream may inject null values into fields that the constructor would usually reject. With a report, the constructor acts as a gatekeeper even throughout deserialization.

Data don’t assist writeObject, readObject, or serialPersistentFields. Their serialized kind is derived solely from their parts, a design determination that deliberately favors predictability and security over customization.

Options to Java serialization

The Externalizable interface is a substitute for Serializable that provides the category full management over the byte format. A category that implements Externalizable should outline writeExternal and readExternal, and should present a public no‑argument constructor:

public class ChallengerExt implements Externalizable {

    personal lengthy id;
    personal String title;

    public ChallengerExt() {} // required

    public ChallengerExt(lengthy id, String title) {
        this.id = id;
        this.title = title;
    }

    @Override
    public void writeExternal(ObjectOutput out) throws IOException {
        out.writeLong(id);
        out.writeUTF(title);
    }

    @Override
    public void readExternal(ObjectInput in) throws IOException {
        this.id = in.readLong();
        this.title = in.readUTF();
    }
}

In contrast to Serializable, no discipline metadata or discipline values are written mechanically. The category descriptor (class title and serialVersionUID) continues to be written, however the developer is absolutely liable for writing and studying all occasion state.

As a result of writeExternal and readExternal work instantly with primitives and uncooked values, fields ought to use primitive sorts the place potential. Utilizing a wrapper sort reminiscent of Lengthy with writeLong would throw a NullPointerException if the worth had been null, since auto‑unboxing can’t deal with that case.

This strategy can produce extra compact output, however the developer is absolutely liable for versioning, discipline ordering, and backward compatibility.

In follow, Externalizable isn’t utilized in fashionable Java. When a full management over-the-wire format is required, most groups select Protocol Buffers, Avro, or related schema‑based mostly codecs as a substitute.

Conclusion

Java serialization is a low-level JVM mechanism for saving and restoring object state. Recognized for being highly effective however unforgiving, serialization bypasses constructors, assumes secure class definitions, and gives no computerized security ensures. Used intentionally in tightly managed programs, it may be efficient. Used casually, it introduces delicate bugs and severe safety vulnerabilities. Understanding the trade-offs mentioned on this article will assist you to use serialization accurately and keep away from unintended misuse.