Draft Object Serialization Specification for records - serialVersionUID
peter.levart at gmail.com
Tue Oct 8 12:37:51 UTC 2019
On 10/7/19 5:37 PM, Chris Hegarty wrote:
>> 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.
More information about the amber-spec-experts