> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 26 Juillet 2019 03:05:20 > Objet: Re: Records: migration compatibility
>> 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." It's true if a user control all the codes that uses the enum values, but once you use external libraries (by example a JSON serializer like jackson that serialize object and enum differently), you start to have a more strict view of what is binary compatible or not. >> 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. for records, we have a reflection method to extract the name of component of the primary constructor, you can not do that with a class, at best you have a de-constructor but it's a positional way to see the values of a record, no a named way to see the values of a record. So again, migration from a record to a class will depend if you use third party libraries that use reflection or not. >> 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…. Rémi
