Draft Object Serialization Specification for records - serialVersionUID
peter.levart at gmail.com
Mon Oct 7 14:17:47 UTC 2019
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:
>>> This spec will be updated to reflect the upcoming core reflection
>>> changes for RecordComponent.
>>> Comments welcome.
>> 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?
I was thinking of the following scenario:
- there is a record-like class C with serialVersionUID != 0 in a library
- 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
An example from a real world:
Library v1 can in reality be JDK N
Library v2 can in reality be JDK N+1
More information about the amber-spec-experts