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.
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?
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.
Regards, Peter
