Civilizer - let's civilize those primitive types !

[Anderson Vasconcelos Pires]

Hi Remi!

Interesting... What would be the purpose of it? Create code that can have
backward compatibility and get benefits when running with jdk-valhalla?

Because I do not see differences between:

value record Foo(int value) and @Value record Foo(int value);

How about the case below:

@Value class A { int value;} // not record! before jdk-17 // value is not
final too.

var a = new A();
a.value = 10; // I expect a compile error if we use value instead of @Value;

Would I be obligated to make the value field final?

Regards,
Anderson.

On Tue, Jan 10, 2023 at 7:39 PM Remi Forax <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/
>
> The prototype works with the latest valhalla early access build
>   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/20230111/f6d94afe/attachment.htm>