Why is the state of an inherited (non-serializable parent) field lost after a serialize/deserialize round-trip, and how can you preserve it?

## Background terms **Serializable** is a marker interface (`java.io.Serializable`) that flags a class as eligible to be turned into bytes via `ObjectOutputStream` and rebuilt via `ObjectInputStream`. **A field is "inherited"** when it is declared in a superclass but accessible/visible in a subclass instance. **`writeObject`/`readObject`** are special, optional methods a serializable class may declare to take manual control of how it is written and read. ## Why parent state is lost When serialization writes an object, it climbs the inheritance chain and serializes the declared fields of **each class that itself implements Serializable**. If the superclass does NOT implement Serializable, its fields are **skipped** — they never enter the byte stream. On deserialization, Java must still construct a whole object. For the non-serializable superclass portion, since there is no data in the stream, Java calls the superclass's **no-argument constructor** and runs the normal constructor chain for that non-serializable part. The serializable subclass's fields are then populated directly from the stream (no subclass constructor runs). Result: any field that lived in the non-serializable parent is reinitialized by the parent's no-arg constructor to its default/constructed value — **not** to the value the object had at serialization time. From the outside it looks like the inherited state "vanished." ``` class Account { // NOT Serializable protected String currency; // inherited field public Account() { this.currency = "USD"; } // no-arg ctor sets default } class SavingsAccount extends Account implements Serializable { private double balance; } ``` Serialize a `SavingsAccount` whose `currency` was changed to `"EUR"`; after deserialization `currency` is back to `"USD"` (set by `Account()`), while `balance` survives because `SavingsAccount` is Serializable. ## How to preserve it The serializable subclass takes over the I/O for the parent's fields by implementing the two special methods: ```java class SavingsAccount extends Account implements Serializable { private double balance; private void writeObject(java.io.ObjectOutputStream out) throws java.io.IOException { out.defaultWriteObject(); // writes SavingsAccount's own fields (balance) out.writeObject(currency); // manually write the inherited parent field } private void readObject(java.io.ObjectInputStream in) throws java.io.IOException, ClassNotFoundException { in.defaultReadObject(); // restores balance; Account() already ran this.currency = (String) in.readObject(); // overwrite the default with saved value } } ``` Key points: - `defaultWriteObject()`/`defaultReadObject()` handle the subclass's own serializable fields; you add manual writes/reads only for the parent fields you want to keep. - This is only possible if the subclass **can access** the parent fields — they must be `protected`, package-private (same package), or reachable through `public`/`protected` getters and setters. If they are `private` with no accessor, the subclass cannot read or restore them, and this technique fails. - The parent's no-arg constructor still runs first; your `readObject` then overwrites the defaults with the saved values. ## Design caveats - This pattern is **fragile**: it manually duplicates knowledge of the parent's fields; adding a field to the parent silently breaks the round-trip until you update `writeObject`/`readObject`. - Constructor side effects in the parent still fire on deserialization. - Often the better answer is to avoid relying on Java serialization for objects with non-serializable ancestors: convert to a serializable DTO, use JSON, or make the whole hierarchy serializable if you own it. ## Summary Inherited non-serializable-parent state is lost because it is never written and the parent is rebuilt via its no-arg constructor. You can preserve it by manually writing/reading those fields in the subclass's `writeObject`/`readObject` — but only when the fields are accessible, and at the cost of a brittle, hand-maintained coupling.