<div dir="ltr">Hi Remi!<div><br></div><div>Interesting... What would be the purpose of it? Create code that can have backward compatibility and get benefits when running with jdk-valhalla?</div><div><br></div><div>Because I do not see differences between:</div><div><br></div><div>value record Foo(int value) and <a class="gmail_plusreply" id="gmail-plusReplyChip-0">@Value </a>record Foo(int value);</div><div><br></div><div>How about the case below:</div><div><br></div><div>@Value class A { int value;} // not record! before jdk-17 // value is not final too.<br></div><div><br></div><div>var a = new A();</div><div>a.value = 10; // I expect a compile error if we use value instead of <a class="gmail_plusreply" id="gmail-plusReplyChip-2">@Value;</a></div><div><br></div><div>Would I be obligated to make the value field final?</div><div><br></div><div>Regards,</div><div>Anderson.</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 10, 2023 at 7:39 PM Remi Forax <<a href="mailto:forax@univ-mlv.fr">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">Hi all,<br>
i've developed a small prototype of what the semantics for the next round could be<br>
  <a href="https://github.com/forax/civilizer/" rel="noreferrer" target="_blank">https://github.com/forax/civilizer/</a><br>
<br>
The prototype works with the latest valhalla early access build<br>
  <a href="https://jdk.java.net/valhalla/" rel="noreferrer" target="_blank">https://jdk.java.net/valhalla/</a><br>
<br>
Basically, everything is an object, using @Value in front of a class or a record transforms it to a value class, a class with no identity<br>
(== compares the fields, synchronized throws an IllegalMonitorStateException, new WeakRef<>(...) throws an IdentityException).<br>
Adding @ZeroDefault means that the default value of the value class which is not null is all fields filled with zero.<br>
<br>
@NonNull allows to declare a non-null type (there is also @Nullable which is the default if there is no null aware annotation).<br>
For parameters, like Kotlin, sending null to a parameter of a method annotated with @NonNull throws a NPE.<br>
For a field a zero-default annotated with @NonNull ask for flattening, trying to store null also throws a NPE.<br>
For a field which is not a zero-default, even if declared @NonNull, the runtime will *not* throw a NPE because the field is null before reaching its initialization assignment in the constructor (and a constructor can call any methods).<br>
<br>
>From the VM POV, a Q-type never appears inside a method descriptor. It appears inside field descriptor but putfield, getfield and withfield allows a field declared as a Q-type to be accessed as a L-type (this is currently simulated for getfield and putfield with an invokedynamic). This is very similar to the way the VM deals with arrays. And the VM knows if a parameter is a Q-type or not despite the fact that only L-type appears in the method descriptor because the Q-type are declared in the Preload table of the class. <br>
<br>
It means that if a class/record is not accessed directly by a constructor but by some static factories (like Optional) then moving in between an identity type, a value type (with zero-default or not) are backward compatible changes.<br>
<br>
regards,<br>
Rémi<br>
</blockquote></div>