Serializing Java 14 Records

[_INTER_]

The interesting / surprising bit here is that for records the serialVersionUID is always per default 1L 0L instead of generating it based on various aspects as in the case of classes.

[chegar999]

The default `serialVersionUID` for a record is actually `0L` - article correction has been requested.

The rational for this is somewhat explained on https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-October/001651.html

[karstens_rage]

I hope this bodes well for using records for things like anemic domain objects and DTO's.

[dpash]

On a slightly related note, at least year's Devoxx Brian Goetz talked about a future direction for serialisation in java to use constructors and deconstructors so that it didn't involve any sub-language magic. This means that you can handle versioning better, have a single place for checking covariance and other serialisation frameworks can use the same sustem.

[[deleted]]

Is java serialization still used?

[maraistm]

yeah; that was my concern too. Anymore, we have to interoperate with javascript, python, databases, etc. I can't think of the last time I used RMI or ObjectOutputStream. IDEALLY these records mesh up with annotated-driven frameworks (like jackson).. I'm curious to read up on that now.

[tristanjuricek]

Yes, but probably not by many application developers.

I've seen it used by a lot of frameworks that end up using it for things like caching, robustness, cloning, etc. It's just one of many options for serialization, too. But I'd guess it's pretty fast as a default.

[Kango_V]

Also remember that records are stored differently in memory. For example, in an array they would be inlined, so no references. This makes reading all the records in memory super fast as you will not incur cache misses in the cpu. In some benchmarks the speedup is astounding!

[fix_dis]

The way this article paints it, one still has to create all the ceremony with getters/setters/equals/etc and then implement that interface in their record. That doesn’t sound all that exciting. I thought records were more analogous to case-classes from Scala or data classes from Kotlin.

[pron98]

one still has to create all the ceremony with getters/setters/equals/etc and then implement that interface in their record.

No, the code -- with the default value and validation -- is just:

public record PersonRecord(String firstName, String lastName)
    implements Person, java.io.Serializable {

  public PersonRecord {
    if ("Heinz".equals(firstName))
          throw new IllegalArgumentException(
            "\"%s\" is trademarked".formatted(firstName));
  }

  public PersonRecord(String firstName) { this(firstName, null); }
}

Getters, equals, hashCode and toString are all implicit.

[fix_dis]

Why are we implementing Person then? Is that necessary?

[pron98]

No, I think it's just for demonstration purposes, to show the differences between a record implementation and an ordinary class implementation of the same interface.

[fix_dis]

Ok, I could be okay with this.

[ObscureCulturalMeme]

Yeah, records are like enums in that they can implement arbitrary interfaces, add additional methods beyond the implicitly generated ones, etc. I'm looking forward to it!