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.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.
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
