Draft Object Serialization Specification for records - construction/destruction

[Peter Levart]

On 10/7/19 3:31 PM, Chris Hegarty wrote:
> 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??

I suggest nothing. He will quickly realize that he can't meaningfully 
implement readExternal method and abandon the attempt. I don't even 
think there has to be special code for instances that implement 
Externalizable if they are records.

Regards, Peter