Draft Object Serialization Specification for records - serialVersionUID

[Peter Levart]

Hi Chris,

On 10/7/19 5:37 PM, Chris Hegarty wrote:
> Peter,
>
>> On 7 Oct 2019, at 15:17, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> ...
>> 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?
> One way, yes. Both ways, no.
>
>> An example from a real world:
>> Library v1 can in reality be JDK N
>> Library v2 can in reality be JDK N+1
>
> Good scenario. I like to think of this as the N-1 scenario ( rather than N+1 ;-) )
>
> So, similar to what you previously suggested, maybe:
>   1) Allow the serialVersionUID to be explicitly declared in a record ( to support the above cross-release interoperability ).
>   2) The default would still be 0L, and the typical record author ( not caring about cross-release interoperation ) will not need to declare it.
>   3) When the local class is a record, the serialVersionUID is effectively ignored when deserializing ( no checks )
>
On one hand, point 3 ensures that users serializing class C -> 
deserializing record C don't have to bother specifying explicit 
serialVersionUID for the record type, but OTOH it also gives false sense 
of assurance that new (record) serialization format is compatible with 
old (class) format for deserializing into instances of class. It does 
however cover a number of real-world use cases. So I'm not on one side 
or another about point 3.

Regards, Peter