> On 23 Aug 2019, at 16:43, Brian Goetz <[email protected]> wrote:
>
>
>>> What about serialVersionUID?
>> The serialVersionUID is allowed and taken into consideration ( sorry, I
>> accidentally omitted this important point ). Setting the serialVersionUID is
>> required, to be able to migrate from a record-like class to a record. Since
>> the former and latter will likely have different default serialVersionUID’s,
>> if not explicitly set ( which one is encouraged to do ).
>
> So, what we'll need here is guidance for:
Yes, good point. Guidance will be needed.
> - compiler writers, what to generate if no svuid is explicitly specified;
Currently not setting an explicit suid is a lint warning, e.g. :
$ cat Foo.java
import java.io.*;
public class Foo {
record A () implements Serializable { }
static class B implements Serializable { }
}
$ javac -Xlint:serial Foo.java
Foo.java:4: warning: [serial] serializable class A has no definition of
serialVersionUID
record A () implements Serializable { }
^
Foo.java:6: warning: [serial] serializable class B has no definition of
serialVersionUID
static class B implements Serializable { }
^
2 warnings
, which seems reasonable, and consistent between classes and records.
> - migrators, what to do when migrating from a class to a record.
The guidance is: explicitly set a suid. Which should be familiar to anyone
preserving serial compatibility when modifying a serializable class in the
current version of their library and requiring interoperability with a previous
version.
I think I’m starting to see why you raised the question about whether or not
checking the suid is really necessary! I guess it protects against accidental
changes that could impact on previous serial forms. That said, an argument
could be made that that check could be handled to the canonical constructor.
-Chris.
