Draft Object Serialization Specification for records - construction/destruction

[Chris Hegarty]

Brian, Peter,

On 09/10/2019 19:52, Brian Goetz wrote:
> ...
> I think there is room to support the future.  Here are some ways we could extract the state from a record for serialization:
>  A. Scrape the fields.
>  B. Call the field accessors.
>  C. Invoke the canonical deconstructor (when we have them.)
>  D. Invoke a serialization-specific pattern if there is one (when we support them.)
> Note that in a case of `record R(...) { }`, these are all the same -- the default accessors return the field values, and the default canonical deconstructor invokes the accessors.
> Clearly, if the user provides an explicit serialization member (whatever that looks like), we should use that in preference to "default" serialization; this is true for classes and records alike, it's just that the default behavior differs between classes and records.  So when we get to New And Improved Serialization, D presents no migration problem; we can say "if there is a serialization pattern, use that, otherwise..."

Sure, makes sense.

> We can make the same argument for C, since in the absence of an explicit dtor, which you can't write now, what you'd get from an implicit dtor is the result of B.  Same story: "if there is a canonical ctor, use that."

Agreed. So we can effectively decouple C & D from this discussion. Great.

> The real question is A vs B.  One can make an argument that serialization is about raw object state, which means that field-scraping is OK.  Or one can make the argument that we are trying to make serialization safer, so we should prefer the accessor (when there is one.)  Most of the time, though, if there is a nontrivial accessor, all it will do is make a copy (say, if the corresponding component is an array), so going through the accessor is a bit of a wasted effort.

The current wording in the draft comes from the desire to be precise on the deserializing-side, to ensure that record construction respects the object model. We may have overrotated on the serializing-side. It sounds like there is room for both A and B.

The proposed draft wording ( as referenced in Peter's earlier email ), from section 1.13 "Serialization of Records" [1] is:

 "The serialized form of a record object is a sequence of values derived from the final instance fields of the object."

This is not wrong ( remember the serialized-form is a description of the on-wire representation, not a description of how to derive the actual values ), but the word could be improved. Suggest:

 "The serialized form of a record object is a sequence of values derived from the record components."

The other area of the proposed draft spec where this impacts ( as referenced in Peter's earlier email ), is 2.1 "The ObjectOutputStream Class” [2]:

  "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.  … "

I think that this is ok as is. It leave room for both A and B.

-Chris.

[1] https://cr.openjdk.java.net/~chegar/records/spec/records-serialization.03.html#serialization-of-records
[2] http://corelibs-linux-1.ie.oracle.com/~chhegar/webrevs/sv2/record/spec/records-serialization.html#the-objectoutputstream-class