> > enums is a counter example here, no ? > > for enums, the only refactoring allowed is from a class to an enum, > the other direction doesn't work because all enums inherits from > java.lang.Enum.
In reality, compatibility is not a binary thing. Yes, if the client depends on Enum methods, then migrating in the other direction will fail. But if the client depends only on the enum constants, it is fine, because resolving EnumClass.X is done with getstatic either way. Its not unlike adding a method; adding a method is generally considered source compatible, but not if there is another method of the same name and same arguments but different return type. There are all sorts of asterisks associated with “binary compatible” and “source compatible." > given that a record already have a different behavior at runtime than a > nomrla class (the Record attribute), > a public abstract class (AbstractRecord), the migration B seems unlikely. With enums, the migration in both directions is common. Class-to-enum was common when we had classes using the type safe enum pattern; but its not uncommon to exceed what can be done with an enum, and refactor back to a class. I could imagine the same happening with records quite easily. > BTW, AbstractRecord also has the nasty side effect of not allowing inline > record. Good point. We’ve been talking about whether inline classes should be able to inherit from abstract classes with no state….
