<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Strongly agreed. In fact, I'm ok even if it is only a warning.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">But yes, this shadowing is definitely something I want to avoid at all costs. I understand why it is there, and while I still don't agree with the logic, I begrudgingly accept its existence. Still, in response to shadowing, I always prepend every single instance field I have with `this`, precisely so that I can avoid this problem in my normal code. If I am going to be forced to do this for yet another layer, I want at least a warning.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Here is a slightly related post I made on amber-dev that addresses something in a similar vein. It is a different form of shadowing. <a href="https://mail.openjdk.org/pipermail/amber-dev/2024-April/008704.html">https://mail.openjdk.org/pipermail/amber-dev/2024-April/008704.html</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 20, 2024 at 1:49 PM <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_6591952386759671573m_-5462525421294525127zimbraEditorContainer" style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><hr id="m_6591952386759671573m_-5462525421294525127zwchr"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"attila kelemen85" <<a href="mailto:attila.kelemen85@gmail.com" target="_blank">attila.kelemen85@gmail.com</a>><br><b>To: </b>"Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>><br><b>Cc: </b>"amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank">amber-dev@openjdk.org</a>>, "Gavin Bierman" <<a href="mailto:gavin.bierman@oracle.com" target="_blank">gavin.bierman@oracle.com</a>>, "jdk-dev" <<a href="mailto:jdk-dev@openjdk.org" target="_blank">jdk-dev@openjdk.org</a>><br><b>Sent: </b>Saturday, April 20, 2024 7:35:34 PM<br><b>Subject: </b>Re: New candidate JEP: 468: Derived Record Creation (Preview)<br></blockquote></div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr">The compilation strategy doesn't matter. I'm just considering what the JEP implies (at least given my understanding) about the meaning of the code. What you are saying is relevant for binary compatibility (which I don't assume is broken). My problem is that when the example code is recompiled against the new version of `MyRecord`, then according to the JLS `MyProperty.z` shadows the `int z = 26;` (the JEP explicitly states this). So, the compiler must produce different code for the two variants of the record (otherwise it breaks the spec written in the JEP).</div></blockquote><div><br></div><div>Okay, got it !<br></div><div><br></div><div>You are right, this is a serious issue, the semantics is different depending on if MyRecord has a field "z" or not.</div><div><br></div><div>Rémi<br></div><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> ezt írta (időpont: 2024. ápr. 20., Szo, 19:30):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_6591952386759671573m_-5462525421294525127m_-452696381260363822zimbraEditorContainer" style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br><br><hr id="m_6591952386759671573m_-5462525421294525127m_-452696381260363822zwchr"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"attila kelemen85" <<a href="mailto:attila.kelemen85@gmail.com" target="_blank">attila.kelemen85@gmail.com</a>><br><b>To: </b>"amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank">amber-dev@openjdk.org</a>><br><b>Cc: </b>"Gavin Bierman" <<a href="mailto:gavin.bierman@oracle.com" target="_blank">gavin.bierman@oracle.com</a>>, "jdk-dev" <<a href="mailto:jdk-dev@openjdk.org" target="_blank">jdk-dev@openjdk.org</a>><br><b>Sent: </b>Saturday, April 20, 2024 5:49:22 PM<br><b>Subject: </b>Re: New candidate JEP: 468: Derived Record Creation (Preview)<br></blockquote></div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr">I have a backward compatibility concern about this JEP. Consider that I have the following record:<br><div>`record MyRecord(int x, int y) { }`<br></div><br><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><br><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><br><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><br><div>```</div><div>var obj1 = new MyRecord(1, 2);<br>int z = 26;<br>var obj2 = obj1 with { y = z; }<br></div><div>```</div><br><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><br><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><br><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><br><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><br><div>Attila</div></div></blockquote><br><div>Hello, i think you are pre-supposing a specific compiler translation strategy, but it can be compiled like this:</div><br><div>MyRecord obj1 = new MyRecord(1, 2);<br>int z = 26;</div><br><div><div>Object carrier = indy(r);  // create a carrier object by calling all the accessors</div><div>                                       // so the side effects are done before calling the block</div><div>int y = z;</div><div>MyRecord obj2 = indy(carrier, /*y:*/ y);  // create an instance of MyRecord using 'y' and the values in the carrier</div></div><br><div>With the carrier instances working like <a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/runtime/Carriers.java" target="_blank">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/runtime/Carriers.java</a><br></div><br><div>regards,<br></div><div>Rémi<br></div><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com" rel="noopener" target="_blank">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="noopener 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></blockquote></div></div></div></blockquote></div><br></blockquote></div></div></div></blockquote></div>