On 10/7/19 3:31 PM, Chris Hegarty wrote:
Peter,
On 6 Oct 2019, at 23:07, Peter Levart <peter.lev...@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