Draft Object Serialization Specification for records - serialVersionUID

[Chris Hegarty]

Thank you for your feedback Peter.

> On 6 Oct 2019, at 22:23, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Chris,
> 
> On Tuesday, October 1, 2019 12:56:55 PM CEST Chris Hegarty wrote:
>> Please find a link to the draft serialization spec for records:
>> 
>> https://cr.openjdk.java.net/~chegar/records/spec/records-serialization.03.ht
>> ml
>> 
>> This spec will be updated to reflect the upcoming core reflection
>> changes for RecordComponent.
>> 
>> Comments welcome.
>> 
>> -Chris.
> 
> Above draft says:
> 
> """Any serialPersistentFields or serialVersionUID field declarations are also 
> ignored -- all record classes have a fixed serialVersionUID of 0L.
> """
> 
> So how does this work with migration plan? When a record-like class C with 
> serialVersionUID != 0 is migrated to be a record, the stream produced with 
> class C can not be read by a program where C is a record. Or is the value of 
> serialVersionUID in the stream ignored when reading the stream into a record? 

Correct. The serialVersionUID is ignored when the local class is a record.

> In that case writing class C -> reading record C is supported, but what about 
> writing record C -> reading class C ?

Migrating from a record R to a record-like class R, then the record-like class R can be specified with an explicit serialVersionUID of 0L ( since the stream value for the serialVersionUID, of the serialized record object R, will be 0L )

> If you still want to support migration, then perhaps the default 
> serialVersionUID of records could be 0L always, but serialVersionUID field 
> would still be considered when this default needs to be overridden. So for 
> types that are records from day 1, users don't have to bother with 
> serialVersionUID fields, but if a type is migrated from class to record, this 
> can still be supported.

The higher-order bit is that record authors don’t need to write an explicit serialVersionUID. And there is a migration strategy between record-like classes and record classes ( and vice versa ). The draft spec provides both. Do you still think that something needs to be changed here, or have any of the clarifications / comments helped?

-Chris.