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