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

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

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

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?

Mateusz Romanowski


More information about the valhalla-dev mailing list