Thread by @nipafx

"Towards better serialization!"

That's a guiding light of #ProjectAmber and record serialization is the first step. The Inside Java Podcast episode on that topic with Julia Boes and @chegar999 (inside.java/2021/03/08/pod…) gives great insight into how it achieves that. 🧵

1/10

First, what's wrong with regular serialization? In short:

* extralinguistic mechanism (aka "magic")
* undermines encapsulation
* causes security issues
* hinders evolving code
* holds back new Java features

In long (and why it turned out that way), see attached thread.

2/10

https://twitter.com/nipafx/status/1359835273992019969

"The magic is where the sin was" (@BrianGoetz) and so record serialization promises "what you see is what you get", making it:

1. easy to understand
2. no magic
3. more secure
4. more performant

3/10

This can be achieved because data is at the core of both serialization and records (as opposed to regular classes), so there's no impedence mismatch. (Observe how this naturally follows from making records a semantic entity, not just a boilerplate avoider.)

4/10

To serialize, an instance's state needs to be extracted. Easy with records because each component has an accessor.

To deserialize, an instance with the correct state needs to be created. Easy for records because the canonical constructor handles all components.

5/10

Interesting is the handling of serial version UIDs: Their default is 0 and records ignore them (they don't need to match). During deserialization, missing fields are injected with their default value. (Not sure what happens to data for absent fields - ignored, I presume.)

6/10

This covers "easy to understand" and "no magic". As to "more secure":

Invariants now only need to be verified in the constructor, not also during deserialization. And that no magic assigns fields after construction also means that `final` record fields can be truly final.

7/10

What about "more performant"? Compared to classes, records are constrained (final types and final fields) and no magic is required during (de)serialization. This makes the code simpler and faster.

8/10

From 21:48 on, Julia describes how method handles and dynamically computed constants are used to store the deserialization logic in the records class file. This allows for compiler optimizations and can be reused by other serialization frameworks.

9/10

How can you get this bliss into your code?

Be on #Java16, refactor classes to records (don't worry about stored serialized forms, they can be deserialized to classes *or* records), and use one of the frameworks that already support them (e.g. Jackson, Apache Johnzon).

10/10