<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
So, a further thing to keep in mind is that currently, adding fields to records is not even source compatible to begin with. For example, if we have
<div class=""><br class="">
</div>
<div class=""> record Point(int x, int y) { }</div>
<div class=""><br class="">
</div>
<div class="">And a client uses it in a pattern match:</div>
<div class=""><br class="">
</div>
<div class=""> case Point(int x, int y): </div>
<div class=""><br class="">
</div>
<div class="">And then we add an `int z` component, the client will break. (When we are able to declare deconstruction patterns, such a migration could include an XY pattern as well as constructor, but we are not there yet.) </div>
<div class=""><br class="">
</div>
<div class="">I think your mail rests on the assumption that it should be fine to modify records willy-nilly and expect compatibility without a recompile-the-world, but I think this is a questionable assumption. Records will likely have features that ordinary
classes do not yet have access to for a while, making such changes risky. </div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Apr 20, 2024, at 5:49 PM, Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" class="">attila.kelemen85@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">I have a backward compatibility concern about this JEP. Consider that I have the following record:
<div class=""><br class="">
</div>
<div class="">`record MyRecord(int x, int y) { }`<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">```<br class="">
record MyRecord(int x, int y, int z) {<br class="">
public MyRecord(int x, int y) {<br class="">
this(x, y, 0);<br class="">
}<br class="">
}<br class="">
```<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">```</div>
<div class="">var obj1 = new MyRecord(1, 2);<br class="">
int z = 26;<br class="">
var obj2 = obj1 with { y = z; }<br class="">
</div>
<div class="">```</div>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">Attila</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com" class="">mark.reinhold@oracle.com</a>> ezt írta (időpont: 2024. febr. 28., Sze, 21:04):<br class="">
</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" class="">https://openjdk.org/jeps/468</a><br class="">
<br class="">
Summary: Enhance the Java language with derived creation for<br class="">
records. Records are immutable objects, so developers frequently create<br class="">
new records from old records to model new data. Derived creation<br class="">
streamlines code by deriving a new record from an existing record,<br class="">
specifying only the components that are different. This is a preview<br class="">
language feature.<br class="">
<br class="">
- Mark</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>