Draft Object Serialization Specification for records - serialVersionUID

[Peter Levart]

Hi Chris,

On 10/7/19 3:31 PM, Chris Hegarty wrote:
> 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.

I was thinking of the following scenario:

- there is a record-like class C with serialVersionUID != 0 in a library 
version v1
- new version of library v2 migrates this class C into record C
- there are two network peers A and B that communicate using serialized 
C. A is using library version v1, B is using library version v2. Can 
they communicate?

An example from a real world:
Library v1 can in reality be JDK N
Library v2 can in reality be JDK N+1

Regards, Peter