Thank you for your feedback Peter. > On 6 Oct 2019, at 22:23, Peter Levart <peter.lev...@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.