Records: migration compatibility
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Jul 26 01:26:28 UTC 2019
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at 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
> Good point. We’ve been talking about whether inline classes should be able to
> inherit from abstract classes with no state….
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts