How records would fit into Google's codebase

[Brian Goetz]

> 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.).