<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Atilla,
<div><br>
</div>
<div>Further to Brian’s reply, I have updated the JEP to list this phenomenon in a “Risks and Assumptions” section. </div>
<div><br>
</div>
<div>Many thanks,</div>
<div>Gavin<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 20 Apr 2024, at 17:49, Attila Kelemen <attila.kelemen85@gmail.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<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>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>