Java Serialization is well known to be one of the worst features of Java. It's been mentioned as such in various "Ask the Experts" panels over the past few years. Joshua Bloch's book "Effective Java" describes many dangers of serialization, and it devotes an entire chapter to the topic. But isn't this merely a recent group of Java platform designers complaining about a bad design produced by an earlier group of Java platform designers?
In fact, Java serialization was well designed for its intended purposes. In the 1990s, big topics of the day included transparent persistence of objects and distributed objects. Transparent persistence is the ability to save and restore objects without requiring explicit code in those objects. Distributed objects involves the transfer of objects and interactions among objects over a network, as in Java RMI. In the context of the late 1990s, Java Serialization supported both of these goals quite well.
The problem is that, while most of the industry has moved on from these goals, Java Serialization is still embedded deeply and pervasively into the platform. With most obsolescent features, libraries and applications can simply ignore them, and doing so poses no issues. Java Serialization is different. Code that on its face appears correct and secure might have bugs or security holes caused by the mere presence of serialization in the platform, even if that code doesn't use serialization explicitly. In many cases, it is simply not possible for high assurance code to ignore the possibility of serialization. Historically, and continuing to this day, serialization is the direct cause of many bugs and security holes in Java appplications, libraries, and in the JDK itself. Serialization thus imposes costs across the platform that cannot be ignored.
This talk is neither a tutorial on serialization, nor is it merely a rant about how bad Java Serialization is. (We can't guarantee there won't be ranting, however.) It is instead a thorough analysis of a few of the fundamental aspects of the design of Java Serialization that, in retrospect, can be considered flaws. We will then provide examples of bugs in the JDK that resulted directly from these design decisions. Informed by this analysis, we will then proceed to describe potential new mechanisms we are exploring that may eventually replace the current Java Serialization mechanism. The direction of the new mechanism is to ensure that it is well integrated with the language model, and where necessary, that the language model is enhanced to accommodate serialization.
Another strong direction is to make the mechanisms explicit in the source code. This will make it possible to verify and reason about the correctness and security of a program by examining it, without having to consider "extra-lingual" mechanisms or "magical" behavior exhibited by the current Java Serialization mechanism.