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