The future of Serialization
Brian Goetz
brian.goetz at oracle.com
Sat Aug 9 17:20:47 UTC 2014
> I've noticed there's not much interest in improving Serialization on
> these lists. This makes me wonder if java Serialization has lost
> relevance in recent years with the rise of protocol buffers apache
> thrift and other means of data transfer over byte streams.
I sense your frustration, but I think you may be reaching the wrong
conclusion. The lack of response is probably not evidence that there's
no interest in fixing serialization; its that fixing serialization, with
all the constraints that "fix" entails, is just really really hard, and
its much easier to complain about it (and even say "let's just get rid
of it") than to fix it.
> Should Serializable eventually be deprecated? Should Serialization be
> disabled by default? Should a new mechanism be developed? If a new
> mechanism is developed, what about circular object relationships?
As I delved into my own explorations of serialization, I started to
realize why such a horrible approach was the one that was ultimately
chosen; while serialization is horrible and awful and leaky and insecure
and complex and brittle, it does address problems like cyclic data
structures and independent evolution of subclass and superclass better
than the "clean" models.
My conclusion is, at best, a new mechanism would have to live
side-by-side with the old one, since it could only handle 95% of the
cases. It might handle those 95% much better -- more cleanly, securely,
and allowing easier schema evolution -- but the hard cases are still
there. Still, reducing the use of the horrible old mechanism may still
be a worthy goal, even if it can't be killed outright.
More information about the security-dev
mailing list