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
