On 22 Jan 2014, at 15:14, Florian Weimer <fwei...@redhat.com> wrote: > On 01/22/2014 03:47 PM, Chris Hegarty wrote: >> On 22/01/14 13:57, Florian Weimer wrote: >>> On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote: >>>> Posted: http://openjdk.java.net/jeps/187 >>> >>> There's another aspect of the current approach to serialization that is >>> not mentioned: the type information does not come from the calling >>> context, but exclusively from the input stream. >> >> Have you overlooked resolveClass [1], or are you looking for additional >> context? > > I mean something slightly different, so here's a concrete example: Assume we > are deserializing an instance of a class with a String field. The current > framework deserializes whatever is in the input stream, and will bail out > with a ClassCastException if the deserialized object turns out unusable. > Contrast this with an alternative approach that uses the knowledge that the > field String and will refuse to read anything else from the input stream.
Sorry, but I may still be missing your point. From my reading of the code, CCE will only be thrown if the object being deserialized contains a field with a type that does not match the type of the similarly named field in the class loaded by the deserializing context. If there is no value assigned to said field, then it is just ignored. Also, if the type of a field changes, from one version of the class to another, but the name remains the same, then the serialVersionUID will differ. Are you thinking specifically about corrupt/malicious streams, or evolving serializable types? Or a performance optimisation? -Chris. > > -- > Florian Weimer / Red Hat Product Security Team
