<div dir="ltr">I have a backward compatibility concern about this JEP. Consider that I have the following record:<div><br></div><div>`record MyRecord(int x, int y) { }`<br></div><div><br></div><div>One day I realize that I need that 3rd property which I want to add in a backward compatible way, which I will do the following way:</div><div><br></div><div>```<br>record MyRecord(int x, int y, int z) {<br> public MyRecord(int x, int y) {<br> this(x, y, 0);<br> }<br>}<br>```<br></div><div><br></div><div>As far as I understand, this will still remain binary compatible. However, if I didn't miss anything, then this JEP makes it non-source compatible, because someone might wrote the following code:</div><div><br></div><div>```</div><div>var obj1 = new MyRecord(1, 2);<br>int z = 26;<br>var obj2 = obj1 with { y = z; }<br></div><div>```</div><div><br></div><div>If this code is compiled again, then it will compile without error, but while in the first version `obj2.y == 26`, now `obj2.y == 0`. This seems rather nasty to me because I was once bitten by this in Gradle (I can't recall if it was Groovy or Kotlin, but it doesn't really matter), where this is a threat, and you have to be very careful adding a new property in plugin extensions with a too generic name. Even though Gradle scripts are far less prone to this, since those scripts are usually a lot less complicated than normal code.</div><div><br></div><div>I saw in the JEP that on the left hand side of the assignment this issue can't happen, but as far as I can see the above problem is not prevented.</div><div><br></div><div>My proposal would be to, instead of shadowing variables, raise a compile time error when the property name would shadow another variable. Though that still leaves the above example backward incompatible, but at least I would be notified of it by the compiler, instead of the compiler silently creating a bug.</div><div><br></div><div>Another solution would be that the shadowing is done in the opposite order, and the `int z = 26;` shadows the record property (with a potential warning). In this case it would be even source compatible, if I didn't miss something.</div><div><br></div><div>Attila</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com">mark.reinhold@oracle.com</a>> ezt írta (időpont: 2024. febr. 28., Sze, 21:04):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://openjdk.org/jeps/468" rel="noreferrer" target="_blank">https://openjdk.org/jeps/468</a><br>
<br>
Summary: Enhance the Java language with derived creation for<br>
records. Records are immutable objects, so developers frequently create<br>
new records from old records to model new data. Derived creation<br>
streamlines code by deriving a new record from an existing record,<br>
specifying only the components that are different. This is a preview<br>
language feature.<br>
<br>
- Mark</blockquote></div>