Record Serialization - Update

Chris Hegarty chris.hegarty at
Fri Aug 23 15:57:52 UTC 2019

> On 23 Aug 2019, at 16:43, Brian Goetz <brian.goetz at> 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 

  public class Foo {
    record A () implements Serializable { }

    static class B implements Serializable { }
  $ javac -Xlint:serial warning: [serial] serializable class A has no definition of serialVersionUID
      record A () implements Serializable { }
      ^ 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list