Replace the primitive class with a more general null safety?

[Glavo]

>
> the language-level types V and P are *reference types* (so P is an alias
> for P.ref in the ref/val model.)  I won't rehash the arguments in favor
> and against here, but this means any "unadorned" type is a reference
> type, regardless of whether it is an identity, value, or primitive
> class.  In this way, all primitive/value classes are "ref favoring", and
> there's no explicit way to flip this, so no need for the
> ref-default/val-default syntax of a previous round.  One of the benefits
> of this is that migration is smoother because migrating an identity
> class to either of the new buckets is source- and binary-compatible.
>

Well done! This is the best news I have heard recently.

It sounds like the information I'm getting from the JEP docs is outdated,
so there's a misunderstanding.
Do you have plans to update JEP 401?

On Fri, Dec 2, 2022 at 3:11 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> On 12/1/2022 12:50 PM, Glavo wrote:
> > Optional.val? Do you mean that the reference-favoring primitive class
> > still exists?
>
> Not quite.
>
> The names in the model have changed over the iterations, but the
> concepts basically have stayed the same.  Some of the classes we want to
> write with Valhalla are just "objects without identity", but are not
> really "like primitives"; LocalDateTime is an example of this.  Others
> are much closer to pure numerics, such as Complex or HalfFloat, and are
> much more "like primitives".  A key difference is that one has a natural
> zero and can therefore be used uninitialized (like int fields), whereas
> the other does not and therefore must be handled through a reference,
> whose initial value is null.  (Though we can still obtain some
> substantial optimizations even for these reference types.)  We've been
> calling these "bucket 2" (objects without identity) and "bucket 3"
> (primitive-like types), which in the more recent model were described
> with value classes and primitive classes.
>
> Regardless of the stacking, a primitive class gives rise to TWO types,
> which I'll call P.val and P.ref here.  One is a reference type, the
> other is a value type.  These are analogous to int and Integer, and they
> have the usual array of differences: nullability, default values, direct
> vs indirect, tearing under race, etc.
>
> A pretty clear decision that has emerged is that for both
>
>      value class V { }
> and
>      primitive class P { }
>
> the language-level types V and P are *reference types* (so P is an alias
> for P.ref in the ref/val model.)  I won't rehash the arguments in favor
> and against here, but this means any "unadorned" type is a reference
> type, regardless of whether it is an identity, value, or primitive
> class.  In this way, all primitive/value classes are "ref favoring", and
> there's no explicit way to flip this, so no need for the
> ref-default/val-default syntax of a previous round.  One of the benefits
> of this is that migration is smoother because migrating an identity
> class to either of the new buckets is source- and binary-compatible.
>
> > For migration related matters, I don't think you need me to introduce
> > these, but I just remind you that although they are very basic,
> > they often don't get the attention they deserve, thus becoming an
> > obstacle to migration.
>
> One of the reasons Valhalla is taking so long is we take migration
> compatibility very seriously.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20221203/5cd11177/attachment.htm>