Read on Twitter
"When people ask me what feature do I most regret, serialization is the easy answer" - @BrianGoetz
Let's talk about serialization in Java: Why does it exist? What are the problems (even today)? Would Java have been better off without it? Can it be fixed?
1/11
Let's talk about serialization in Java: Why does it exist? What are the problems (even today)? Would Java have been better off without it? Can it be fixed?
1/11
NB: What follows is mostly quotes or paraphrasing from a conversation I had with Brian during my 25-hour live stream. If you want to watch the full discussion about serialization, nullability, primitives, and more, you can find it here:
2/11
2/11
Serialization was introduced because turning an object graph into bytes is valuable: You can store things on disk, in databases, or send them over the wire. But while the concept is sound, it was implemented in a horrible way.
"I wasn't on the team at the time" - Brian
3/11
"I wasn't on the team at the time" - Brian
3/11
Serializable objects have three aspects:
1. internal representation (mostly fields)
2. API (public members)
3. external form
With serialization, 1. and 3. are identical by default. One problem is that custom 3. is cumbersome ( https://nipafx.dev/java-serialization-proxy-pattern/ or `Externalizable`).
4/11
1. internal representation (mostly fields)
2. API (public members)
3. external form
With serialization, 1. and 3. are identical by default. One problem is that custom 3. is cumbersome ( https://nipafx.dev/java-serialization-proxy-pattern/ or `Externalizable`).
4/11
Another problem is that serialization bypasses the constructor (to allow serializing circular object graphs). As a result, it exists outside the language and outside the object model (thus often called "extralinguistic").
"The magic is where the sin was." - Brian
5/11
"The magic is where the sin was." - Brian
5/11
So why was it implemented this way?
* serializing circular graphs is tough
* the language didn't have features suitable for an "intralinguistic" solution
* usual project pressures
* foresight isn't 20/20
And this has not been without consequences...
6/11
* serializing circular graphs is tough
* the language didn't have features suitable for an "intralinguistic" solution
* usual project pressures
* foresight isn't 20/20
And this has not been without consequences...
6/11
Its extralinguistic character is why serialization undermines encapsulation, hinders evolving code, causes security issues, and holds back new Java features.
"Serialization is a full-employment act for vulnerability engineers" - @stuartmarks
7/11
"Serialization is a full-employment act for vulnerability engineers" - @stuartmarks
7/11
Add to that how rarely it's used today and it makes sense to wonder, would Java have been better off without it?
Brian suspects it wouldn't. Java first became strong on the server side and serialization was essential for distributed object frameworks like EJB or RMI.
8/11
Brian suspects it wouldn't. Java first became strong on the server side and serialization was essential for distributed object frameworks like EJB or RMI.
8/11
For desktop apps, being able to reliably read/write state from/to disk without having to create code for it can be very valuable as well. One promise of OOP was that reflection would largely automate persistence.
"That was amazing!" - Brian
9/11
"That was amazing!" - Brian
9/11
So without releasing serialization in late 90s, Java may not have been successful and we may not have this conversation today. Indeed, today's problems come from yesterday's solutions.
How can we solve this one?
10/11
How can we solve this one?
10/11
By using more powerful language features (starting with records) and accepting a smaller feature set (no circular graphs), there may be a much more sensible serialization mechanism in Java's future.
I'm looking forward to what Brian and the other JDK devs come up with!
11/11
I'm looking forward to what Brian and the other JDK devs come up with!
11/11
