How records would fit into Google's codebase

Alan Malloy amalloy at
Wed Apr 3 20:35:47 UTC 2019

On Wed, Apr 3, 2019 at 11:53 AM Brian Goetz <brian.goetz at> wrote:

> Of those that extend a class other than Object, do you spot any common
> cases, either specific classes or classes with specific characteristics?

Good question! I'm surprised I didn't already look into this - I guess
since I had misread your proposal as allowing subclassing, I didn't think
too hard about the superclasses.

The most frequent specific superclasses turns out to be Guice's
at 6.5%. I'm not familiar with Guice, but my understanding is that a record
R extends AbtractModule in order to put a factory for R objects in some
kind of generic factory registry. I imagine Guice is a lot more popular
here than in the rest of the world, so I would not expect that to represent
records in general.

Perhaps more interesting, the three next-most-common superclasses are
"convergent evolution" of an identical class (but with a different name)

public abstract class ToStringless {
  public final String toString() {
    return super.toString();

This class prevents @AutoValue from synthesizing a toString() method, so
Object.toString() gets locked in. Often this is used for a string which may
be "sensitive", but perhaps there are other use cases. Of records with
superclasses, 9% have something like this as their superclass. No state,
just behavior. There's another superclass that also fixes identity-based
hashCode and equals(). If we include this in the count, we get over 10%.

After that, many of the common superclasses seem to be "abstract records":
an abstract class that defines a number of fields for @AutoValue to
implement, plus a method or two that uses those fields to conform to some

Two funny ones stuck out to me: java.lang.Exception and
java.lang.RuntimeException! Makes sense, right? People want to bundle data
up in their exceptions, and what better way to bundle data than as a
record? Still, this makes up only about 1% of records with superclasses.
These classes look about like you'd expect: they just hold a couple fields,
nothing fancy.

You also mentioned factory methods as an alternative to constructors. I
don't see this as helping much: it's still positional, and wouldn't get
names to the call sites.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list