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

[Peter Firmstone]

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.
>