Serialization & Reflection
Serialization and reflection look like different jobs, but both are about the same thing — crossing the boundary between a live object in memory and something outside it. Serialization turns an object's state into a byte stream you can store on disk or send over a network and later rebuild. Reflection lets code look inside a class at runtime — list its fields and methods and reach them by name — even for types the compiler knew nothing about.
These two mechanisms are what the "magic" of frameworks is built on: DI containers create objects from a class name, ORMs map a table row onto entity fields, serializers persist arbitrary objects. The price is that both bypass ordinary guarantees: serialization ignores the constructor and excludes transient / static fields, while reflection breaks encapsulation and defers errors to runtime. The full map lives in the layers below.
Topic map
- Serialization — the
Serializablemarker interface,serialVersionUID, the object graph, and what never reaches the stream. - The transient keyword — fields excluded from serialization, and why they come back empty.
- The Reflection API — the
Classobject, runtime introspection, and the cost of that flexibility.
Common traps
| Mistake | Consequence |
|---|---|
Forgetting an explicit serialVersionUID | The auto-generated one shifts on any class change — reading an old stream throws InvalidClassException |
| Assuming every field is serialized | transient and static fields are not written to the stream |
| Expecting the constructor to run on deserialization | For a Serializable class the constructor does not run — the object is built around it |
Assuming a transient field keeps its value | After a read it gets the type default (null / 0 / false) |
Referencing a non-Serializable object from a serializable one | NotSerializableException at write time |
| Using reflection in a hot loop | It is noticeably slower than a direct method call |
Reaching private members via reflection without setAccessible(true) | IllegalAccessException; and the module system (JPMS) can forbid even that |
Interview relevance
This comes up less than collections or concurrency, but it probes depth well: do you understand that serialization is about bytes and version compatibility rather than JSON, and where reflection is justified versus over-engineering.
Typical checks:
- What
Serializabledoes and howserialVersionUIDaffects version compatibility. - Which fields are not serialized (
transient,static) and whether the constructor runs on a read. - What reflection is, which object it works through (
Class), and what it costs. - Where reflection is genuinely needed (frameworks) versus where plain polymorphism suffices.
Common wrong answer: "serialization is just turning an object into JSON." That opens the discussion that Java's built-in serialization writes a binary format, pulls in the whole graph of reachable objects, and bypasses the constructor — which is exactly why it is treated as a security risk when reading untrusted data.