JEP 187: Serialization 2.0
scolebourne at joda.org
Tue Dec 30 14:24:46 UTC 2014
I've checked the bug database , JEPs list  and Google but this
JEP appears to have disappeared. Can this be confirmed?
On 13 February 2014 at 11:05, Florian Weimer <fweimer at redhat.com> wrote:
> On 01/23/2014 03:30 PM, Chris Hegarty wrote:
>> On 22 Jan 2014, at 15:14, Florian Weimer <fweimer at 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.reinhold at 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 , or are you looking for additional
>>> 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 " +
> 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
More information about the core-libs-dev