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

[Peter Levart]

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?

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()? 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.

Regards, Peter