Record Serialization - Update

[Chris Hegarty]

> On 23 Aug 2019, at 16:01, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> ...
>>   - The serial form of a record is it's state components. It is not
>>     customizable (*).
> 
> Must the fields appear in the stream in the canonical order?  Or, are they serialized by name, and then we swizzle them back into the order desired by the canonical constructor?

The stream fields can appear in any order. They are matched to their respective constructor parameter by name. Since, the serial format doesn’t guarantee any ordering, and we wanna be able to go from serializable class Foo to record Foo.

>>   - Serialization will ignore pretty much all of the magic methods, if
>>     they appear in a record (**).
> 
> What about serialVersionUID?

The serialVersionUID is allowed and taken into consideration ( sorry, I accidentally omitted this important point ). Setting the serialVersionUID is required, to be able to migrate from a record-like class to a record. Since the former and latter will likely have different default serialVersionUID’s, if not explicitly set ( which one is encouraged to do ).

> What happens if the fields present are a superset, or subset, of the components in the canonical ctor?

For now, in the yet-to-be-polished prototype, we have:
1) All stream fields are deserialised ( regardless of whether they have a matching component ) - since one of them could be the target of a back reference. This is similar to other non-record data in the stream.
2) Stream fields are matched to their respective component, by name.
3) Components without a corresponding stream field have the appropriate type’s default value passed. The ctr can decide if the default value is allowable or not.

>>   - Record-like class to record migration is supported (and vice versa),
>>     since the stream format is not changed.
> 
> So, if a class C migrates to a record R, the serialized fields are just fed to the canonical ctor.

Right. ( class C migrated to record C - since the type’s name is present in the stream )

> Must serialVersionUID match?

Currently, yes.

>   Or maybe, if at deserialization time it's a record, we just ignore svuid?

That is one possibility, but explicitly declaring the suid seems like a good idea, doesn’t take much effort, is a little safer, and feels natural ( when one wants to preserve backward compatibility with a previous serial-form ).

-Chris.