Fw: Re: RFR [9] 8071472: Add field access to support, setting final fields in readObject

[David M. Lloyd]

I think you didn't understand the issue being discussed - it's not about 
fields that are added/removed, which is very clearly defined in the 
spec.  It's about what happens when you don't call 
defaultRead|WriteFields, which is required by spec but not always done 
in practice.

On 03/20/2015 10:05 PM, Peter Firmstone wrote:
> The reason for this part of the spec, is backward compatible
> evolvability of serial form.
>
> It allows an earlier implementation of a class to deserialize serial
> form from a later implementation that includes additional fields or
> values written to the stream, and allow them to be discarded by
> ObjectInputStream, when the earilier implementation doesn't read/consume
> them.
>
> If classes deliberately break the contract / spec, then although they
> function, they limit their backward compatible evolvability; in other
> words, if a later class has additional fields or writes additional
> values to the stream, a StreamCorruptedException will occur when an
> earlier class implementation reads it.
>
> For that reason, I'd reccommend against including it in the spec.
>
> Regards,
>
> Peter.
>
>
>> ------------------------------
>>
>> Message: 4
>> Date: Fri, 20 Mar 2015 11:57:04 -0500
>> From: "David M. Lloyd"<david.lloyd at redhat.com>
>> To: core-libs-dev at openjdk.java.net
>> Subject: Re: Fw: Re: RFR [9] 8071472: Add field access to support
>>     setting    final fields in readObject
>> Message-ID:<550C5160.2030106 at redhat.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 03/20/2015 09:31 AM, Peter Levart wrote:
>>> On 03/20/2015 02:03 PM, David M. Lloyd wrote:
>>>>>> private static void altReadObject(ObjectInputStream in, FieldAccess
>>>>>> fieldAccess) throws IOException, ClassNotFoundException {
>>>>>>              // the same as in readObject, but doesn't have direct
>>>>>> access to
>>>>>> instance state, so everything must go through FieldAccess API?
>>>>>> }
>>>>>>
>>>>>>
>>>>> Yes.
>>>> An interesting aspect of this approach is that it deals with a problem
>>>> in the serialization spec [1] where it specifically says that
>>>> serializable classes should be reading/writing stream fields always,
>>>> and before reading/writing other data:
>>>>
>>>> In section 3.4: "Either ObjectInputStream's defaultReadObject or
>>>> readFields method must be called once (and only once) before reading
>>>> any optional data written by the corresponding writeObject method;
>>>> even if no optional data is read, defaultReadObject or readFields must
>>>> still be invoked once."
>>>>
>>>> In section 2.3: "Either ObjectOutputStream's defaultWriteObject or
>>>> writeFields method must be called once (and only once) before writing
>>>> any optional data that will be needed by the corresponding readObject
>>>> method to restore the state of the object; even if no optional data is
>>>> written, defaultWriteObject or writeFields must still be invoked once."
>>>>
>>>> But classes (even JDK classes) often disregard this requirement,
>>>> relying on known implementation behavior and either reading/writing
>>>> optional data before fields or just not reading/writing fields at
>>>> all.  So either the spec should be updated (I've tried to do this but
>>>> nobody seems to know how to modify this old content I guess) to match
>>>> behavior, or the spec should be enforced more strictly - however doing
>>>> the latter *will* break a lot of user code, *unless* an alternative
>>>> readObject method is introduced with the more strict enforcement.  But
>>>> I guess even in this case, the spec should be updated to allow the
>>>> implementation behavior.
>>>>
>>>> [1]
>>>> http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
>>>>
>>>>
>>> I guess this would need an alternative writeObject method too, with more
>>> strict enforcement, or not?
>> Sounds fine to me...
>>
>>> I don't know from the top of my head, but does the order of writing
>>> optional data (before or after) fields, change the order of data emitted
>>> in stream and does that order have to be respected when reading back in
>>> readObject()?
>> Yes.
>>
>>> In that case, I guess, we would need an alternative
>>> writeObject method too, with more strict enforcement of order. But I
>>> think that having two different rules for old read/writeObject and
>>> alternative read/writeObject would just confuse people. If current rules
>>> don't present any problem (apart from being looser then specification
>>> requires) then perhaps just specification should be updated.
>> Maybe.
>>
>

-- 
- DML