JVMS draft for L-world value types with support for nullability

[Paul Sandoz]

Hi Fred,

Some basic questions, which might be because the specification is transitioning from value-based to value classes.


> The ACC_ENUM flag indicates that this class or its superclass is declared as an enumerated type. A class file must not have both ACC_ENUM and ACC_VALUE_TYPE flags set.


Why can’t enum classes be values classes, where enum values are actual values? I think the answer may be below.


> The ACC_NON_NULLABLE flag indicates that this field must never store the null reference. The field signature must be the signature of a class. The class specified in the field’s signature is loaded during the loading phase of the class declaring this field. The class of the field must be a value class. This field must be initialized with the default value of this value class.


I suppose in theory this attribute could be applied to a non-value class?


> A field must not have both ACC_STATIC and ACC_NON_NULLABLE flags set. 

This would rule out the static fields of a enum class, although in this case i would presume an enum class is such that after static initializer block all static fields would be assigned since they are also marked final. 

So, if static fields can be final then why not non-nullable?

Thanks,
Paul.


> On Jan 31, 2018, at 11:38 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
> 
> Here’s a draft of the JVMS proposing a way to implement the L-world value types,
> with support for value-based classes migration to value classes (essentially, support
> for nullability):
> 
> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-3.pdf
> 
> The assumptions and key properties are listed in Karen’s document:
> 
> http://cr.openjdk.java.net/~acorn/LWorldValueTypesjan31.pdf
> 
> 
> Feedback and comments are welcome.
> 
> Fred
>