Record Serialization - Update

[Chris Hegarty]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190823/730f9a0c/attachment-0001.html>