I've checked the bug database [1], JEPs list [2] and Google but this JEP appears to have disappeared. Can this be confirmed? Stephen
[1] https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20JEP [2] http://openjdk.java.net/jeps/0 On 13 February 2014 at 11:05, Florian Weimer <fwei...@redhat.com> wrote: > On 01/23/2014 03:30 PM, Chris Hegarty wrote: >> >> 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. > > > This is from the method > ObjectStreamClass.FieldReflector::setObjFieldValues(Object, Object[]), > called indirectly from ObjectInputStream::readObject0(boolean): > > Object val = vals[offsets[i]]; > if (val != null && > !types[i - numPrimFields].isInstance(val)) > { > Field f = fields[i].getField(); > throw new ClassCastException( > "cannot assign instance of " + > val.getClass().getName() + " to field " + > f.getDeclaringClass().getName() + "." + > f.getName() + " of type " + > f.getType().getName() + " in instance of " + > obj.getClass().getName()); > } > > So the exception is thrown after the object val has been read from the > stream, which involves its construction and deserialization. This means > that you always expose the full serialization functionality, no matter with > which types you start. > >> Are you thinking specifically about corrupt/malicious streams, or evolving >> serializable types? Or a performance optimisation? > > > Mostly the former. Sorry, I should have said so. > > There are serialization frameworks which restrict the types of > deserializable objects based on the type of the top-level object being > requested. Or in Java serialization terms, they won't load and instantiate > arbitrary classes even if the programmer did not provide a customer, > restrictive resolveClass() implementation. I get that type-erased generics > make it complicated to achieve this in current Java. (But so is writing a > correct resolveClass() because it breaks encapsulation.) > > Knowing in advance which types to expect in the stream would allow for a > performance optimization, but something like that could be added to the > current framework as well. > > > -- > Florian Weimer / Red Hat Product Security Team
