<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">the language-level types V and P are *reference types* (so P is an alias<br>for P.ref in the ref/val model.)  I won't rehash the arguments in favor<br>and against here, but this means any "unadorned" type is a reference<br>type, regardless of whether it is an identity, value, or primitive<br>class.  In this way, all primitive/value classes are "ref favoring", and<br>there's no explicit way to flip this, so no need for the<br>ref-default/val-default syntax of a previous round.  One of the benefits<br>of this is that migration is smoother because migrating an identity<br>class to either of the new buckets is source- and binary-compatible.<br></blockquote><div><br></div><div>Well done! This is the best news I have heard recently.</div><div><br></div><div>It sounds like the information I'm getting from the JEP docs is outdated, so there's a misunderstanding.<br></div><div>Do you have plans to update JEP 401?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 2, 2022 at 3:11 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</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"><br>
<br>
On 12/1/2022 12:50 PM, Glavo wrote:<br>
> Optional.val? Do you mean that the reference-favoring primitive class <br>
> still exists?<br>
<br>
Not quite.<br>
<br>
The names in the model have changed over the iterations, but the <br>
concepts basically have stayed the same.  Some of the classes we want to <br>
write with Valhalla are just "objects without identity", but are not <br>
really "like primitives"; LocalDateTime is an example of this.  Others <br>
are much closer to pure numerics, such as Complex or HalfFloat, and are <br>
much more "like primitives".  A key difference is that one has a natural <br>
zero and can therefore be used uninitialized (like int fields), whereas <br>
the other does not and therefore must be handled through a reference, <br>
whose initial value is null.  (Though we can still obtain some <br>
substantial optimizations even for these reference types.)  We've been <br>
calling these "bucket 2" (objects without identity) and "bucket 3" <br>
(primitive-like types), which in the more recent model were described <br>
with value classes and primitive classes.<br>
<br>
Regardless of the stacking, a primitive class gives rise to TWO types, <br>
which I'll call P.val and P.ref here.  One is a reference type, the <br>
other is a value type.  These are analogous to int and Integer, and they <br>
have the usual array of differences: nullability, default values, direct <br>
vs indirect, tearing under race, etc.<br>
<br>
A pretty clear decision that has emerged is that for both<br>
<br>
     value class V { }<br>
and<br>
     primitive class P { }<br>
<br>
the language-level types V and P are *reference types* (so P is an alias <br>
for P.ref in the ref/val model.)  I won't rehash the arguments in favor <br>
and against here, but this means any "unadorned" type is a reference <br>
type, regardless of whether it is an identity, value, or primitive <br>
class.  In this way, all primitive/value classes are "ref favoring", and <br>
there's no explicit way to flip this, so no need for the <br>
ref-default/val-default syntax of a previous round.  One of the benefits <br>
of this is that migration is smoother because migrating an identity <br>
class to either of the new buckets is source- and binary-compatible.<br>
<br>
> For migration related matters, I don't think you need me to introduce <br>
> these, but I just remind you that although they are very basic,<br>
> they often don't get the attention they deserve, thus becoming an <br>
> obstacle to migration.<br>
<br>
One of the reasons Valhalla is taking so long is we take migration <br>
compatibility very seriously.<br>
<br>
<br>
</blockquote></div>