Could the idea of null-default inline classes be revisited?

Mateusz Romanowski romanowski.mateusz at gmail.com
Wed May 6 17:29:48 UTC 2020


Hi,
The idea of null-default value types was raised years ago [1], however, I
believe it was dropped.

Considering that one of the reasons for Project Valhalla was, I believe,
not to have to choose between using safe abstractions (validating
constructor) and flat memory layout, replacing unsafe fields (ie.
firstName:Ljava/lang/String;, lastName:Ljava/lang/String;) with safe inline
value (ie. person:Qpkg/Person;) that wrap, should be easy without
surprising average developer.

Unfortunately, as Person.default cannot model real person, the developer
needs to learn new idiom for *some* inline types (comparing to default
value instead of null check) and learn that instanceof/cast no longer
rejects all impossible values.

Also, if generalizing the idea of migration of primitive type and its
wrapper class [2] into value and reference projection, we might consider
void/Void migration.

If void becomes alias for value projection java.lang.void and
java.lang.Void is its reference projection, then Void value set consists of
void.default and null. This would be a paradox, unless void.default becomes
null.


I think that those might be reasons for introducing L-envelope-using [3]
null-default inline types/classes.

Are there any chance for having vulls?

Thanks,
Mateusz Romanowski

[1] https://cr.openjdk.java.net/~jrose/values/nullable-values.html
[2] http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
[3]
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001288.html


More information about the valhalla-dev mailing list