Civilizer - let's civilize those primitive types !

[forax at univ-mlv.fr]

> From: "Red IO" <redio.development at gmail.com>
> To: "Anderson Vasconcelos Pires" <andvasp at gmail.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Sent: Thursday, January 19, 2023 9:19:09 PM
> Subject: Re: Civilizer - let's civilize those primitive types !

> If we talk about the user model for the explicit nullability of refrences we
> should think about allowing the developer to turn it around. Meaning that every
> reference is treated non null when not marked otherwise. But this should
> definitely strictly be "an option" that you can enable somehow.
> This can be really beneficial since the compiler can mark every point where an
> (default) non nullable is assigned (potential) null value or a nullable
> variable is dereferenced at all.
> I just got the idea of inverting the nullability default from c# which has this
> feature. I recently flipped it on one of my projects and the entire code lit up
> with warnings. Showing countless spots where a null check was missing.
> It would be logical to use "!" for explicit non-null and "?" for explicit
> nullable. With 1 being optional in each case rather the default is inversed or
> not.

This is what the annotation @NullMarked of jspecify does [1], but again, this thread is about getting the VM model right, not getting the Java semantics right. 

> Great regards
> RedIODev

[1] https://jspecify.dev/ 

> On Wed, Jan 11, 2023, 18:30 Anderson Vasconcelos Pires < [
> mailto:andvasp at gmail.com | andvasp at gmail.com ] > wrote:

>> Thanks for the prompt response!

>>>> Mostly prototyping a proposal to remove Q-types (descriptor that starts with
>>>> Q...;) and replace them by an attribute on methods and fields indicating if the
>>>> value can be null.

>>> see [
>>> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-January/002217.html
>>> |
>>> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-January/002217.html
>>> ]

>> So if you want to remove Q types it means that L type does not need the identity
>> information, right?

>>> There is no notion of .val or .ref, if you want a field to be flattened, use a
>>> @Zero-Default and declare the field @NonNull.

>> Pretty good if we do not need to use .val or .ref!

>> Could the @NonNull be replaced by "!" but writing the attribute in the class
>> file?

>> I Like @NonNull but I believe the "!" would be more practical.

>> As @Nullable is the default, maybe it would not be necessary to have it.

>>>> yes, the prototype does not do any verification that the compiler does, i'm too
>>>> lazy for that but the VM will catch you and throw an Error

>> Pretty good for a prototype!

>>> About the mutability of fields, fundamentally, value type is about saying, i
>>> give up the notion of identity, if you have no identity, you have no location
>>> in memory (you can have more than one if you prefer) so the VM is free to pass
>>> by reference or pass by value. So you can not mutate a field, because you can
>>> only do that if you have one location in memory.

>> Ok for mutability but now I am a little bit confused about references, identity
>> and memory location. Value class is a reference type that does not have
>> identity. So it means that it can be allocated in the heap, right? So
>> allocating it in the heap will have a memory location, do not?

>>>> regards,

>>> Rémi

>> Thanks for the explanation!

>> Regards,
>> Anderson.

>>>> On Tue, Jan 10, 2023 at 7:39 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
>>>> forax at univ-mlv.fr ] > wrote:

>>>>> Hi all,
>>>>> i've developed a small prototype of what the semantics for the next round could
>>>>> be
>>>>> [ https://github.com/forax/civilizer/ | https://github.com/forax/civilizer/ ]

>>>>> The prototype works with the latest valhalla early access build
>>>>> [ https://jdk.java.net/valhalla/ | https://jdk.java.net/valhalla/ ]

>>>>> 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
>>>>> (== compares the fields, synchronized throws an IllegalMonitorStateException,
>>>>> new WeakRef<>(...) throws an IdentityException).
>>>>> Adding @ZeroDefault means that the default value of the value class which is not
>>>>> null is all fields filled with zero.

>>>>> @NonNull allows to declare a non-null type (there is also @Nullable which is the
>>>>> default if there is no null aware annotation).
>>>>> For parameters, like Kotlin, sending null to a parameter of a method annotated
>>>>> with @NonNull throws a NPE.
>>>>> For a field a zero-default annotated with @NonNull ask for flattening, trying to
>>>>> store null also throws a NPE.
>>>>> 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).

>>>>> 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.

>>>>> 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.

>>>>> regards,
>>>>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230119/b2a9087c/attachment.htm>