Civilizer - let's civilize those primitive types !

[Remi Forax]

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