How records would fit into Google's codebase

Brian Goetz brian.goetz at
Wed Apr 3 20:46:08 UTC 2019

> 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 {
>   @Override
>   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%.

OK, so these fall into the narrow gap between what interfaces can do and what abstract classes can — implement Object methods.  That’s interesting, and worth remembering.  

Of course, it’s also easy to implement toString() in the record (and would be even lower overhead with something like CMB.). 

More information about the amber-spec-experts mailing list