I feel like Remi has a good point somewhere in here, though I'm not sure I can articulate it any better than he does....
On Wed, Jan 21, 2026 at 12:02 PM Brian Goetz <[email protected]> wrote: > So there are two stabled, principled alternatives: > > - Just don't ever try to derive equals and hashCode > - Derive equals and hashCode similarly as for records > > And of course, the first means that records cannot be considered special > cases of carriers. So the latter seems a forced move. > Hmm... why not? Can we not say: "A record is a special case of a carrier that ... and also auto-generates equals() and hashCode()" ? [ There is some implied heresy here, which is that maybe it was wrong for records to auto-generate equals/hashCode in the first place. I found it a bit surprising the first time I tried to put some public record GraphNode objects into a Set and inadvertently created a bunch of infinite loops which I had to fix by overriding equals() with == and hashCode() with System.identityHashCode(). But obviously that horse is out of the barn... ] In other words, I like Remi's conceptual idea of carrier classes being "(possibly abstract) things with virtual components". Really that's almost like saying "modernized java beans". Then a record could still be a specialized, locked down, concrete form of a carrier class. -Archie -- Archie L. Cobbs
