If a Serializable class extends a non-serializable superclass, what extra requirement must the superclass meet, and why?

## Setup: what serialization is **Serialization** is converting a live Java object (its fields, recursively) into a byte stream so it can be saved to disk or sent over a network. **Deserialization** is the reverse: reconstructing the object from those bytes. In core Java this is done with `ObjectOutputStream.writeObject(obj)` and `ObjectInputStream.readObject()`. A class opts in by implementing the **marker interface** `java.io.Serializable` (an interface with no methods; it just flags the class as serializable). ## The scenario Consider a serializable class whose **superclass** (parent class it `extends`) is NOT serializable: ``` class Animal { // NOT Serializable String species; } class Dog extends Animal implements Serializable { // IS Serializable String name; } ``` This is **allowed** and works — but with an important asymmetry. ## What gets written vs. what gets restored When you serialize a `Dog`, the serialization machinery walks up the class hierarchy and serializes the fields of every class **in the chain that is itself Serializable**. Here only `Dog` is Serializable, so only `Dog`'s field `name` is written. The fields declared in `Animal` (e.g. `species`) are **not** written to the stream — the non-serializable superclass's state is simply not captured. On **deserialization** Java must build a complete object including the `Animal` part. Since the `Animal` fields are not in the stream, Java cannot read them back. Instead, the deserialization process **calls the no-argument constructor of the first non-serializable superclass** (here `Animal()`), and lets the normal constructor chain run for the non-serializable part. That constructor reinitializes the parent's fields to whatever defaults/values the no-arg constructor sets (so `species` will be whatever `Animal()` assigns, NOT the value the object had before serialization). The serializable subclass's fields (`name`) are then filled in from the stream — **without** running `Dog`'s constructor. ## The requirement, precisely Because Java must call that no-arg constructor, the non-serializable superclass **must have an accessible no-arg (no-argument) constructor**. "Accessible" means visible to the subclass: `public`, `protected`, or package-private when in the same package. If the superclass: - declares **no** constructors at all → the compiler supplies an implicit public no-arg constructor → fine. - declares **only** parameterized constructors → there is no no-arg constructor → **fails**. - has a no-arg constructor but it is **private** → not accessible → **fails**. When the requirement is violated, deserialization throws `java.io.InvalidClassException` complaining that the class has no valid (accessible no-arg) constructor. (Serialization, i.e. writing, generally still succeeds; the failure surfaces at read time.) ## The contrast that trips people up For a **Serializable** superclass, its constructor is **NOT** called on deserialization — the object is allocated and its fields are populated directly from the stream, bypassing constructors entirely. For a **non-serializable** superclass it is the opposite: its no-arg constructor **IS** called. So the rule of thumb is: *constructors run for the non-serializable part of the hierarchy and are skipped for the serializable part.* ## Practical consequences 1. Any state held in the non-serializable parent is **lost** across a serialize/deserialize round-trip unless you explicitly preserve it (e.g. by giving the subclass `writeObject`/`readObject` methods that read and re-set the parent's fields). 2. Side effects in the parent's no-arg constructor (logging, ID generation, registering with a registry) **will execute** during deserialization — sometimes unexpectedly. 3. If you control the parent, the cheapest fix to a deserialization failure is to add an accessible no-arg constructor.