<div dir="ltr"><p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> A pretty clear decision that has emerged is that for both</i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> value class V { }</i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> and</i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> primitive class P { }</i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> the language-level types V and P are *reference types* (so P is an alias<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> for P.ref in the ref/val model.) I won't rehash the arguments in favor<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> and against here, but this means any "unadorned" type is a reference<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> type, regardless of whether it is an identity, value, or primitive<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> class. In this way, all primitive/value classes are "ref favoring", and<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> there's no explicit way to flip this, so no need for the<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> ref-default/val-default syntax of a previous round. One of the benefits<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> of this is that migration is smoother because migrating an identity<span class="gmail-Apple-converted-space"> </span></i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><i>> class to either of the new buckets is source- and binary-compatible.</i></p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:14px"><i></i><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">For backwards compatibility (and greater simplicity) this is clearly a better solution — it follows the well-known Integer vs int distinction much more closely — but does this imply that the ‘P.val’ designation will no longer be available for primitive object fields? (I assume the P.ref designation is redundant and so can be deleted.) I think the answer has to be ‘No’, so maybe I’m just asking that the JEP 401 description be updated.</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">The ability to be able to specify a P field in a value class as a P.val type allows it to be specified as non-nullable (like being able to specify a field as either a nullable Integer or non-nullable int). It allows more efficient storage (no extra bit to denote null or non-null) and so easier inlining.</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">It also potentially allows the compiler to automatically cause an NPE or other appropriate exception to be thrown if a client attempts to instantiate an object containing a required P.val field with a null input value. An example:</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>value class ContactInfo {</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>private PhoneNumber.val mobile;<span class="gmail-Apple-converted-space"> </span>// required, non-nullable</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>private PhoneNumber landLine;<span class="gmail-Apple-converted-space"> </span>// nullable, often missing</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>...<span class="gmail-Apple-converted-space"> </span>// PhoneNumber is a primitive class</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>ContactInfo(PhoneNumber pn1, PhoneNumber pn2) {</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>Objects.requireNonNull(pn1, “mobile”);</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>this.mobile = pn1;<span class="gmail-Apple-converted-space"> </span></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>this.landLine = pn2;</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>}</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>}</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">If the constructor is autogenerated (e.g. in a record), will the compiler augment the byte code to throw an exception if pn1 = null? Or better still, cause the following client code to be rejected?</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>PhoneNumber landLine = new PhoneNumber(...);</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>ContactInfo info = new ContactInfo(null, landLine); <span class="gmail-Apple-converted-space"> </span>// invalid code</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">It shouldn’t be necessary to have to specifhy ‘.val’ explicitly in constructor parameters; the compiler has the information in the field type.</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">Indeed, it would be nice if one could specify any value class field as non-nullable, *regardless* of whether the field type is a primitive class. That would enable the compiler and JVM to store/flatten the field without having to allocate space to store a distinguishing bit for null (and also to autogenerate an exception if a null is passed for that field to a constructor). Using the Objects.requireNonNull method alone doesn’t accomplish the more efficient storage.</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">Example:</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>value class ContactInfo {</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>private nonull EmailAddress email;<span class="gmail-Apple-converted-space"> </span>// required field</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>...</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)"><span class="gmail-Apple-converted-space"> </span>}</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0)">On a different note, the framework now sounds very close to being final. Any chance of a preview version of value and primitive classes in JDK 21? (I’m presuming that the preview feature would allow you to do so while postponing previews of JEP 402 and modified (universal) generics.) Or, if not primitive classes, value classes alone?</p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Courier;color:rgb(0,0,0);min-height:16px"><br></p>
<br></div>