How does serialization traverse an inheritance hierarchy when a superclass is not Serializable?

## Serialization is class-by-class When you serialize an object, the runtime processes the inheritance chain class by class, from the topmost class downward. For EACH class it asks one question: does this class implement `Serializable`? - If **yes**, that class's instance fields participate (its non-`transient`, non-`static` fields are written, or its `writeObject` runs). - If **no**, that class's fields are **completely ignored** — not written to the stream at all. So `Serializable` is not 'all or nothing' for the whole object; it's evaluated at each level. A subclass can be `Serializable` even if its parent is not. ## Writing: the non-serializable parent is skipped Given: ```java class Animal { // NOT Serializable int legs; Animal() { this.legs = 4; } // no-arg constructor Animal(int legs) { this.legs = legs; } } class Dog extends Animal implements Serializable { String name; } ``` When you serialize a `Dog`, only `Dog`'s fields (`name`) are written. `Animal.legs` is NOT in the stream — it's as if the parent's state is `transient`. ## Reading: the parent is rebuilt via its no-arg constructor This is the crucial and frequently-tested rule. To reconstruct the object the runtime must produce a valid `Animal` part before filling in `Dog`'s fields. Since the parent's state wasn't saved, the runtime **calls the non-Serializable superclass's no-arg constructor** to initialize that part. Result for our example: after deserializing a `Dog`, `legs` is whatever `Animal()` sets it to (here `4`), NOT the value the original object had at serialization time. If the original `Dog` had `legs == 3`, that information is lost — it comes back as `4`. Contrast with the Serializable subclass part: for `Dog` itself, NO constructor runs (that's the normal Serializable behavior); its fields are set directly from the stream. So a mixed hierarchy has split behavior: - Non-Serializable ancestors: constructor runs, fields come from constructor/defaults. - Serializable descendants: no constructor runs, fields come from the stream. ## The hard requirement: an accessible no-arg constructor Because the runtime MUST call the superclass's no-arg constructor, that constructor has to exist and be reachable from the serializable subclass (i.e. `public`, `protected`, or package-private in the same package). If the non-Serializable superclass has only argument-taking constructors (and thus no implicit default constructor), deserialization throws: ``` java.io.InvalidClassException: Dog; no valid constructor ``` This happens at deserialization time, not at compile time, which makes it an easy production surprise. ## Why this design? It preserves the contract that a non-Serializable class never has its state silently persisted (it opted out), while still letting subclasses be serializable. Running the parent's no-arg constructor guarantees the inherited part is in a valid, initialized state. ## Practical guidance - If you need a superclass's fields to survive, make the superclass `Serializable`, or capture/restore those fields manually in the subclass's `writeObject`/`readObject`. - Always ensure a non-Serializable superclass that you intend to extend with serializable subclasses has an accessible no-arg constructor. - Treat non-Serializable superclass fields as effectively transient when reasoning about round trips.