Records: migration compatibility

[forax at univ-mlv.fr]

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

> Good point. We’ve been talking about whether inline classes should be able to
> inherit from abstract classes with no state….

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190726/7d6d5dce/attachment-0001.html>