Hi Chris,
On 10/7/19 5:37 PM, Chris Hegarty wrote:
Peter,
On 7 Oct 2019, at 15:17, Peter Levart <peter.lev...@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
