Draft Object Serialization Specification for records - serialVersionUID
Chris Hegarty
chris.hegarty at oracle.com
Mon Oct 7 13:31:44 UTC 2019
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.
More information about the amber-spec-experts
mailing list