When Records Meet Serialization A Happy Tale
summary
Records in JDK 16 change serialization by making the serialized form derive only from declared record components and by reconstructing objects via the canonical constructor called last, not by bypassing constructors. The implementation stops reflection backdoors (no setAccessible hacks), reads values bottom-up, drops unknown fields, and throws on invariant failures (example: null or negative height causes NPE during deserialization). Result: same byte-stream shape for migration, stronger security, and no window where an impossible object exists.
AI-written summary · about
chapters (5)
- 0:00Introduction
- 1:47Java serialization flaws
- 12:21What are records
- 23:57Records and serialization
- 30:02Summary and benefits
related talks
46mJava Records for the Intrigued
54mData Oriented Programming with the JDK 19
42mBetter Modeling Through Records
37mRecords, Not Just Constant Classes, A Deep Dive
53mWhy We Hate Java Serialization And What We're Doing About It
13mThe Record: Migrate to Immutability
51mSerialization: A New Hope
23mSerialization 2.0