Draft Object Serialization Specification for records - construction/destruction

[Chris Hegarty]

Peter,

> On 6 Oct 2019, at 23:07, Peter Levart <peter.levart at gmail.com> wrote:
> 
> On Sunday, October 6, 2019 11:38:42 PM CEST Peter Levart wrote:
>> Hi Chris,
>> 
>> I think that if stream values deserialize into a record through its public
>> API (the canonical constructor which can be customized), then record
>> components that are serailzed must also be obtained from a record via its
>> public API (the accessors which can also be customized).
>> 
> 
> ...above discussion also extends to the ObjectOutputStream.writeObject method 
> description that is currently written as:
> 
> """If the object is a record object, the ObjectStreamClass for the class of 
> the record object is written by recursively calling writeObject. It will 
> appear in the stream only the first time it is referenced. A handle is 
> assigned for the record object.
> 
> The components of the record object are written to the stream.
> 
> a.  If the record object is serializable or externalizable, the record
>     components are written, as if by invoking the `defaultWriteObject`
>     method.
> 
> b.  If the object is neither serializable or externalizable, the
>     `NotSerializableException` is thrown.
> 
> The writeObject method then returns.
> """
> 
> So instead of "as if by invoking the `defaultWriteObject`, here you might want 
> to describe how component values are obtained, etc.

Answered in another email.

> But I wanted to comment on another thing here: "a. If the record object is 
> serializable or externalizable, ..."
> 
> How could record be Externalizable? It would have to implement 
> writeExternal(ObjectOutput). No big deal. It would also have to have a public 
> no-arg constructor. No big deal. It would have to implement 
> readExternal(ObjectInput). Wait! How could a record type effectively implement 
> readExternal if all record fields are final?

Yeah, Externalizable and records are just at odds. The only possible useful externalizable record is a record with no components!  Externalizable is a bit of a wart here, but was included for consistency.

> Externalizable and records don't play together well, I think. If a record type 
> wishes to fully customize serialization format it still can designate a 
> serialization proxy (via writeReplace()) which can be an instance of a normal 
> Externalizable class for example.
> 

I agree, writeReplace is the correct escape hatch for folk that want something other than the default scheme. The is why it is there.

I’m not opposed to dropping support for Externalizable. Is that the suggestion? What should happen if one writes `record R (int x, int y) implements Externalizable { … }`  -  a warning or not? maybe an error during serializing / deserializing?? 

-Chris.