Records: supertype?

[Brian Goetz]

We've gone back and forth a few times on whether records should have a 
special supertype, as enums do (java.lang.Enum.)

Enums benefit from having an explicit supertype for a number of reasons:

  - It provides a type bound that is useful in API signatures (e.g., 
EnumSet<E extends Enum<E>>);
  - The base class actually has state;
  - It provides declarations of public methods such as `ordinal()`, 
`compareTo()`, and `getDeclaringClass()`, and implementations of methods 
such as `toString()` and `readObject()`;
  - It declares supertypes such as `Comparable`;
  - It provides a place to capture specification of enum-specific 
behavior, in a way that is more discoverable within the IDE than putting 
it in the JLS.

One could make the same argument that records should similarly have an 
explicit supertype (e.g., `AbstractRecord`), but the arguments aren't as 
decisive:

  - No state in the base class;
  - No record-specific methods or supertypes (currently);
  - Hard to imagine `<T extends AbstractRecord<T>>` showing up in APIs, 
though it's possible.

Which is to say, the choice of whether or not to have a base class for 
records is less obvious.  Still:

  - The specification for equals/toString/hashCode for records is 
somewhat refined over that of Object, and putting it in the Javadoc is 
the sensible place to put it;
  - One can imagine wanting to add methods like `toJson()` to records in 
the future, and an abstract base class is a sensible place to put it.

So, one could make a case for "do the simplest thing" (no supertype), 
or, alternately, be more like enums, and still get some benefits.

If we decide to go for the supertype, there's a bikeshed to paint.  
Record is the obvious analogue to Enum, but I worry that it will create 
clashes with user code (java.lang names are always auto-imported.)  
AbstractRecord feels a little clunky.  (Once you've weighed in on the 
first question, you can proceed to the bikeshed.)