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

[David M. Lloyd]

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