What is Externalizable in Java, and how does it differ from Serializable?

## The problem both solve: object serialization **Serialization** means turning a live in-memory object into a flat sequence of **bytes** that can be written to a file, sent over a network, or cached — and later **deserialized** (read back) into an equivalent object. Java's built-in mechanism is driven by two writer/reader classes, `ObjectOutputStream` (writes objects to bytes) and `ObjectInputStream` (reads bytes back into objects). Java offers **two ways** to opt a class into this mechanism. ## 1. `Serializable` — automatic `java.io.Serializable` is a **marker interface**: an interface with **no methods**. You just declare `implements Serializable` and add nothing else. The marker is a flag that tells `ObjectOutputStream` "you are allowed to serialize me." The runtime then uses **reflection** (inspecting the class's fields at runtime) to automatically write out every non-`static`, non-`transient` field, plus class metadata describing the field names and types. ```java class Point implements Serializable { int x, y; // both written automatically } ``` - `transient` fields are **skipped** (not written). - `static` fields belong to the class, not an instance, so they are not written. - On deserialization the JVM **does not call any constructor** of the class — it allocates the object directly and fills its fields from the stream. ## 2. `Externalizable` — manual `java.io.Externalizable` **extends** `Serializable` but adds **two methods you must implement**: ```java void writeExternal(ObjectOutput out) throws IOException; void readExternal(ObjectInput in) throws IOException, ClassNotFoundException; ``` When `ObjectOutputStream` sees a class is `Externalizable`, it writes **almost nothing automatically** — it just records the class identity and then calls **your** `writeExternal`, where you explicitly write each value (`out.writeInt(x)`, `out.writeObject(name)`, …). On the way back, the runtime: 1. Calls the class's **public no-arg constructor** to create a blank instance, then 2. Calls **your** `readExternal`, where you read the values back **in the exact same order** you wrote them and assign them to fields. Because of step 1, **a public no-arg constructor is mandatory** for an `Externalizable` class. If it's missing (or not public), deserialization throws `InvalidClassException`. ## The core trade-off | Aspect | `Serializable` | `Externalizable` | |---|---|---| | Effort | Zero (marker only) | Write both methods by hand | | Format control | Runtime decides | You decide every byte | | Constructor on read | None called | **Public no-arg** called | | Speed / size | Slower, larger (reflection + metadata) | Can be faster, more compact | | Error surface | Low | High — you maintain the format | | `transient` honored | Yes | Irrelevant — you write only what you choose | ## Why the no-arg constructor? `Serializable` deserialization uses a special JVM path that constructs the object **without** running its constructors, restoring exact saved state. `Externalizable` instead reconstructs by the ordinary route — create an empty object via the no-arg constructor, then let your `readExternal` fill it — so that constructor must exist and be accessible. ## When to use which Use `Serializable` by default; it is simpler and correct for the vast majority of cases. Reach for `Externalizable` only when you have a measured need for a smaller/faster custom format and you are willing to own the format's correctness and versioning by hand. In modern systems, many teams avoid native Java serialization entirely in favor of JSON, Protobuf, or Avro for cross-language stability and security.