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

[Frederic Parain]

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

Re: 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  
> 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
> 

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

[Frederic Parain]

Hi Paul,

> On Jan 31, 2018, at 15:50, Paul Sandoz  wrote:
> 
> 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.

First of all, there’s a backward compatibility issue with old enums. They have 
been defined with full identity,
which is incompatible with being a value type.
There’s also an issue with the super-type. The super-type of all enums is the 
abstract class java.lang.Enum,
but the super-type of a value class must be java.lang.Object.
One advantage of values types is that the JVM can flattened them, it is 
possible because of two properties:
being identity-less and having a default value. Without a default value, the 
JVM cannot initialized a non-nullable
field, so flattened cannot be performed,

> 
> 
>> 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?

No as it is define today, because of the lack of non-null default value for 
non-value class, which makes the initialization
of such field impossible for the JVM.

A future project might be to enable ACC_NON_NULLABLE for non-value class, but
it would require a much complex initialization scheme, probably involving indy 
or condy.
This is way beyond the scope of this draft.

> 
> 
>> 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?

This is an open question.

The rational of the current choice is to avoid some circularity errors with some
common construct for static fields.

The ACC_NON_NULLABLE flag is a marker for the JVM that indicates where 
flattening
is possible. The gain of flattening static fields is very small compared to the 
gains of
flattening of instance fields or array components. And the risk of circularity 
errors is high.
For instance, it is impossible to for a value class to have a static field with 
ACC_NON_NULLABLE
of its own type. Static fields are initialized during the preparation phase 
(JVMS 5.4.2),
which means for these fields  to store the default value of the class, but the 
class
has not been fully initialized yet, so it is still impossible to create such 
default values.
The problem exists also with indirect references to the current class (cycles).

So allowing ACC_NON_NULLABLE for static fields would require to write a new set
of restrictions in the language about when the flag can be used and and it 
cannot.
We saw theses constraints as a useless burden for the language (because the 
purpose
of the flag is to enable some implementation optimizations), so we proposed
to simply forbid them.

If the language team thinks there’s more value in allowing ACC_NON_NULLABLE, we
can revisit the current choice.

Fred


> 
> 
>> On Jan 31, 2018, at 11:38 AM, Frederic Parain  
>> 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
>> 
> 

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

[John Rose]

On Jan 31, 2018, at 9:38 PM, Frederic Parain  wrote:
> 
> Hi Paul,
> 
>> On Jan 31, 2018, at 15:50, Paul Sandoz  wrote:
>> 
>> 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.
> 
> First of all, there’s a backward compatibility issue with old enums. They 
> have been defined with full identity,
> which is incompatible with being a value type.
> There’s also an issue with the super-type. The super-type of all enums is the 
> abstract class java.lang.Enum,
> but the super-type of a value class must be java.lang.Object.
> One advantage of values types is that the JVM can flattened them, it is 
> possible because of two properties:
> being identity-less and having a default value. Without a default value, the 
> JVM cannot initialized a non-nullable
> field, so flattened cannot be performed,

Good summary.  Although it is desirable to evolve enums to value types,
we would have to figure out a migration strategy that would allow us to
recompile them into value types, but also allow old code to operate
correctly on them.  I don't think this is an easy problem, in L-world or
any other world.

A JVM could do a heroic optimization on a field of enum type, if the
enum type were loaded before the class containing the field.  That
would be an instructive project, I think, but it is not an important one.

> 
>> 
>> 
>>> 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?
> 
> No as it is define today, because of the lack of non-null default value for 
> non-value class, which makes the initialization
> of such field impossible for the JVM.
> 
> A future project might be to enable ACC_NON_NULLABLE for non-value class, but
> it would require a much complex initialization scheme, probably involving 
> indy or condy.
> This is way beyond the scope of this draft.

I agree.  The JVM would have to somehow track the initialization state
of a non-nullable field, forcing each constructor to initialize it, and 
preventing
access before initialization.  (Idea:  Use null internally, and have getfield
throw NPE if there is accidental access before construction is complete.)

> 
>> 
>>> 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?
> 
> This is an open question.
> 
> The rational of the current choice is to avoid some circularity errors with 
> some
> common construct for static fields.

Don't we have similar circularity problems with non-static fields?  Why are
static fields worse?  One answer:  You have to create the Class mirror
very early (during preparation), and we use Class mirrors to store static
field values.

value class A { static flat B BVAL; }
value class B { static flat A AVAL; }

Thus, preparing A requires the layout of B, and vice versa.  To me this
seems like an inconvenience, not an inherent flaw of flat statics.

Maybe a crude but effective way to break the bootstrap cycle is to
store BVAL and AVAL with internal references, initialized to null.
Then, have getstatic silently convert the internal nulls to default
values.  It's a cheat, but nobody would know.

Or, more simply, convert flat statics into one-element arrays,
again as an internal cheat:

value class A { static B[] $INTERNAL$ARRAY$BVAL = new B[1]; }

Then getstatic would secretly load the first (and only) element of the
one-element array which stores the static.  It might also have to
recognize a null array reference, during bootstrapping, and "load"
a default value from the not-yet-existing array.

> 
> The ACC_NON_NULLABLE flag is a marker for the JVM that indicates where 
> flattening
> is possible. The gain of flattening static fields is very small compared to 
> the gains of
> flattening of instance fields or array components. And the risk of 
> circularity errors is high.
> For instance, it is impossible to for a value class to have a static field 
> with ACC_NON_NULLABLE
> of its own type.

I hope we c

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

[John Rose]

On Jan 31, 2018, at 7:38 PM, Frederic Parain  wrote:
> 
> http://cr.openjdk.java.net/~acorn/LWorldValueTypesjan31.pdf 
> 
> 
> 
> Feedback and comments are welcome.

A couple more comments about Object as an "honorary interface":

As your document suggests, I don't think we have a real option to
make a new top type I$Object that is a proper interface.  Instead,
we have to get into the habit of treating Object like an interface.

The cost of this is pretty small, I think.  Mainly we have to treat
the "messy" API of Object (wait/notify/finalize) as a set of partial
functions, which can throw exceptions (or have some other empty
behavior) when applied to values.

— John

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

[Paul Sandoz]

Hi Fred, John,

Thanks for the explanations, very informative.

Regarding enums i was not thinking of the case of implicitly retrofitting all 
enum classes to be value classes (that would be tricky as you point out). I was 
wondering if it might be possible for an enum class to also explicitly be a 
value class, e.g.:

__Value enum MyEnumValue { 
V1, V2, V3; 
}

(placing aside compatibility issues of an explicit transition, and even though 
it inherits from abstract class Enum), since enum is anyway special cased in 
some ways, but perhaps not sufficiently to make it easy to do.

Thanks,
Paul.
 

> On Feb 1, 2018, at 6:34 AM, John Rose  wrote:
> 
> On Jan 31, 2018, at 9:38 PM, Frederic Parain  
> wrote:
>> 
>> Hi Paul,
>> 
>>> On Jan 31, 2018, at 15:50, Paul Sandoz  wrote:
>>> 
>>> 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.
>> 
>> First of all, there’s a backward compatibility issue with old enums. They 
>> have been defined with full identity,
>> which is incompatible with being a value type.
>> There’s also an issue with the super-type. The super-type of all enums is 
>> the abstract class java.lang.Enum,
>> but the super-type of a value class must be java.lang.Object.
>> One advantage of values types is that the JVM can flattened them, it is 
>> possible because of two properties:
>> being identity-less and having a default value. Without a default value, the 
>> JVM cannot initialized a non-nullable
>> field, so flattened cannot be performed,
> 
> Good summary.  Although it is desirable to evolve enums to value types,
> we would have to figure out a migration strategy that would allow us to
> recompile them into value types, but also allow old code to operate
> correctly on them.  I don't think this is an easy problem, in L-world or
> any other world.
> 
> A JVM could do a heroic optimization on a field of enum type, if the
> enum type were loaded before the class containing the field.  That
> would be an instructive project, I think, but it is not an important one.
> 
>> 
>>> 
>>> 
 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?
>> 
>> No as it is define today, because of the lack of non-null default value for 
>> non-value class, which makes the initialization
>> of such field impossible for the JVM.
>> 
>> A future project might be to enable ACC_NON_NULLABLE for non-value class, but
>> it would require a much complex initialization scheme, probably involving 
>> indy or condy.
>> This is way beyond the scope of this draft.
> 
> I agree.  The JVM would have to somehow track the initialization state
> of a non-nullable field, forcing each constructor to initialize it, and 
> preventing
> access before initialization.  (Idea:  Use null internally, and have getfield
> throw NPE if there is accidental access before construction is complete.)
> 
>> 
>>> 
 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?
>> 
>> This is an open question.
>> 
>> The rational of the current choice is to avoid some circularity errors with 
>> some
>> common construct for static fields.
> 
> Don't we have similar circularity problems with non-static fields?  Why are
> static fields worse?  One answer:  You have to create the Class mirror
> very early (during preparation), and we use Class mirrors to store static
> field values.
> 
> value class A { static flat B BVAL; }
> value class B { static flat A AVAL; }
> 
> Thus, preparing A requires the layout of B, and vice versa.  To me this
> seems like an inconvenience, not an inherent flaw of flat statics.
> 
> Maybe a crude but effective way to break the bootstrap cycle is to
> store BVAL and AVAL with internal references, initialized to null.
> Then, have getstatic silently convert the internal nulls to default
> values.  It's a cheat, but nobody would know.
> 
> Or, more simply, convert fla

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

[John Rose]

On Feb 1, 2018, at 5:24 PM, Paul Sandoz  wrote:
> 
> an enum class to also explicitly be a value class

Yes, it's probably doable, but we would have to work out the
migration story, and also figure out how to manage the Enum
supertype.  Remember that one of the ongoing challenges
of VT's is the role of Object.  For value-enums, I think we
would reprise the role for Enum.  I'd rather have template
classes under my belt before tackling that, so I could make
Enum behave differently as an object vs. a value supertype.

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

[Frederic Parain]

Here’s an update of the JVMS draft:

http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4.pdf

with the following changes:

  * Renamed ACC_NON_NULLABLE with ACC_FLATTENABLE
  * Removed restriction that ACC_FLATTENABLE cannot be used on static fields
  * Added rules about circularity restrictions for fields with the 
ACC_FLATTENABLE flag set
  * Added rules about initialization of classes of flattenable fields 

Fred

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

[Karen Kinnear]

Frederic,

Detailed review of the updated JVMS draft - many are just minor typos/edits. A 
couple
are bigger. Many thanks for the latest changes.

thanks,
Karen

1. 2.4 Reference Types and Values
" whose all instances are identity-less and immutable"
"whose" -> "for which"

2. 2.11.5 Instance Creation and Manipulation
4th bullet: non-staticfields - need a space)

3. 4.1 The Classfile Structure
"If none of the ACC_VALUE_TYPE or the ACC_INTERFACE flag is set"
-> "If neither the ACC_VALUE_TYPE ..."

4. 4.4.1 The CONSTANT_Class_info Structure

Because arrays are objects, ... "but not the opcode new" - perhaps "but not the 
opcodes new or defaultvalue".

5. 4.9.1. Static Constraints
  getfield, putfield, getstatic, putstatic -- also withfield - must refer to a 
CONSTANT_FieldRef

6. 4.9.1 Static Constraints
   operands of instanceof, checkcast, new ...
 - also include defaultvalue

7. 4.9.1 Static Constraints
   No defaulvalue instruction may reference a constant pool entry ...
   - fix indentation

8. 5.3.5 Deriving a Class from a class File Representation
   3. Note that if C is an interface it must have Object as its direct 
superclass, ...
change to "if C is an interface or a value class"

9. 5.3.5 Deriving a Class from a class File Representation
   3. "If the class or interface named as the direct superclass of C is in fact 
an interface, ...
change to "is in fact an interface or value class" -> ICCE


10. 5.3.5 Deriving a Class from a class File Representation
  5. Change ACC_VALUE_TYPE flag to ACC_FLATTENABLE

  5. Perhaps word: If C has any non-static field FC with the ACC_FLATTENABLE 
flag set,  in order
 to use F below in the exception case

  5. Exceptions:
  Rather than triggering a StackOverflwError, I was expecting a 
ClassCircularityError
  * If any of the fields marked as ACC_FLATTENABLE is not in fact a value 
class, loading throws
an ICCE
  * Otherwise, if any of the ACC_FLATTENABLE fields contains directly or 
indirectly the class C or the
  class FC, loading throws a ClassCircularityError


11. 5.3.5 Deriving a Class from a class File Representation
   5.  So it looks as though you have made a change to allow ACC_FLATTENABLE on 
an object class.
   I recognize there have been requests to support that in the future, but 
I think that will
   require additional discussions before I would make a JVMS change.

   Perhaps a bit of non-normative text here say in italics?
   i.e. we do not allow a value class to migrate to an object class
   - intention is to allow declaration of a ACC_FLATTENABLE to imply 
non-nullable for
   object classes as well as value classes?
   - I would leave this out until we have had further detailed discussions

12. 5.5. Initialization
   Thank you for adding  step 8 to pre-initialize an ACC_FLATTENABLE field.
   Can you also add this to the bullets under "may be initialized only as a 
result of:

   * If C is a reference type and a containing class declares a field C with the
 ACC_FLATTENABLE flag set ...


13. General question
   Would it make sense to disallow an Interface to define a field with 
ACC_FLATTENABLE?

14. Chapter 6:
  putfield "withe" -> "with the"
  I need to double-check - I was expecting a runtime, not a linktime NPE due to 
ACC_FLATTENABLE.
  Does linktime actually know the value you are writing?

15. Chapter 6:
  putstatic
mentions null for value class type throws NPE, but I think that is intended 
to be if
ACC_FLATTENABLE, and again - isn't this a run-time exception?

16. Chapter 6:
   new: if finds interface, abstract class or value class -> throws 
InstantiationError
   defaultvalue: if interface or abstract class, throws InstantiationError
 if object class, throws ICCE

We can ask Dan Smith what he prefers here. Given it is ok to migrate object 
class to value class, but
not value class to object class, perhaps it is appropriate to have asymmetric 
errors.

17. Chapter 6:
   withfield
   typo: vwithtfield =204
   same question: NPE - isn't that a runtime exception



> On Feb 5, 2018, at 2:05 PM, Frederic Parain  
> wrote:
> 
> Here’s an update of the JVMS draft:
> 
> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4.pdf
> 
> with the following changes:
> 
>  * Renamed ACC_NON_NULLABLE with ACC_FLATTENABLE
>  * Removed restriction that ACC_FLATTENABLE cannot be used on static fields
>  * Added rules about circularity restrictions for fields with the 
> ACC_FLATTENABLE flag set
>  * Added rules about initialization of classes of flattenable fields 
> 
> Fred

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

[Frederic Parain]

Karen,

Thank you for this very detailed review.

I’ve fixed all the issues (see comments below), and the updated draft is
available here:

http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4a.pdf

Fred

> On Feb 5, 2018, at 18:31, Karen Kinnear  wrote:
> 
> Frederic,
> 
> Detailed review of the updated JVMS draft - many are just minor typos/edits. 
> A couple
> are bigger. Many thanks for the latest changes.
> 
> thanks,
> Karen
> 
> 1. 2.4 Reference Types and Values
> " whose all instances are identity-less and immutable"
> "whose" -> "for which

Fixed

> 
> 2. 2.11.5 Instance Creation and Manipulation
> 4th bullet: non-staticfields - need a space)
> 

Fixed

> 3. 4.1 The Classfile Structure
> "If none of the ACC_VALUE_TYPE or the ACC_INTERFACE flag is set"
> -> "If neither the ACC_VALUE_TYPE …”

Fixed

> 4. 4.4.1 The CONSTANT_Class_info Structure
> 
> Because arrays are objects, ... "but not the opcode new" - perhaps "but not 
> the opcodes new or defaultvalue”.

Fixed

> 
> 5. 4.9.1. Static Constraints
>   getfield, putfield, getstatic, putstatic -- also withfield - must refer to 
> a CONSTANT_FieldRef
> 

Fixed

> 6. 4.9.1 Static Constraints
>operands of instanceof, checkcast, new ...
>  - also include defaultvalue
> 

Fixed

> 7. 4.9.1 Static Constraints
>No defaulvalue instruction may reference a constant pool entry ...
>- fix indentation

Fixed

> 8. 5.3.5 Deriving a Class from a class File Representation
>3. Note that if C is an interface it must have Object as its direct 
> superclass, ...
> change to "if C is an interface or a value class”
> 

Fixed

> 9. 5.3.5 Deriving a Class from a class File Representation
>3. "If the class or interface named as the direct superclass of C is in 
> fact an interface, ...
> change to "is in fact an interface or value class" -> ICCE
> 

Fixed

> 
> 10. 5.3.5 Deriving a Class from a class File Representation
>   5. Change ACC_VALUE_TYPE flag to ACC_FLATTENABLE
> 

Fixed

>   5. Perhaps word: If C has any non-static field FC with the ACC_FLATTENABLE 
> flag set,  in order
>  to use F below in the exception case
> 


>   5. Exceptions:
>   Rather than triggering a StackOverflwError, I was expecting a 
> ClassCircularityError
>   * If any of the fields marked as ACC_FLATTENABLE is not in fact a value 
> class, loading throws
> an ICCE
>   * Otherwise, if any of the ACC_FLATTENABLE fields contains directly or 
> indirectly the class C or the
>   class FC, loading throws a ClassCircularityError
> 
> 

I’ve re-worked this section. It will have to be reviewed again.

> 11. 5.3.5 Deriving a Class from a class File Representation
>5.  So it looks as though you have made a change to allow ACC_FLATTENABLE 
> on an object class.
>I recognize there have been requests to support that in the future, 
> but I think that will
>require additional discussions before I would make a JVMS change.
> 

My bad. This is not a change, just a leftover of a previous iterations I forgot 
to update.
Current semantic is that it is illegal to set the ACC_FLATTENABLE flag for a 
field
which is an object class.

I’ve fixed this section too.


>Perhaps a bit of non-normative text here say in italics?
>i.e. we do not allow a value class to migrate to an object class
>- intention is to allow declaration of a ACC_FLATTENABLE to imply 
> non-nullable for
>object classes as well as value classes?
>- I would leave this out until we have had further detailed discussions

I’d prefer to keep this idea in our discussion, and not write it down in the 
spec, to avoid
making wrong expectations.

> 
> 12. 5.5. Initialization
>Thank you for adding  step 8 to pre-initialize an ACC_FLATTENABLE field.
>Can you also add this to the bullets under "may be initialized only as a 
> result of:
> 
>* If C is a reference type and a containing class declares a field C with 
> the
>  ACC_FLATTENABLE flag set …
> 
Added

> 
> 13. General question
>Would it make sense to disallow an Interface to define a field with 
> ACC_FLATTENABLE?

Yes, if you want to prevent 

> 
> 14. Chapter 6:
>   putfield "withe" -> "with the”
Fixed

>   I need to double-check - I was expecting a runtime, not a linktime NPE due 
> to ACC_FLATTENABLE.
>   Does linktime actually know the value you are writing?

You’re right, it’s a runtime exception.

> 
> 15. Chapter 6:
>   putstatic
> mentions null for value class type throws NPE, but I think that is 
> intended to be if
> ACC_FLATTENABLE, and again - isn't this a run-time exception?

Fixed

> 
> 16. Chapter 6:
>new: if finds interface, abstract class or value class -> throws 
> InstantiationError
>defaultvalue: if interface or abstract class, throws InstantiationError
>  if object class, throws ICCE
> 
> We can ask Dan Smith what he prefers here. Given it is ok to migrate object 
> class to value class, but
> not value class to object c

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

[Karen Kinnear]

Paul,

Just to make sure we are in sync for now:

I think we are all in agreement that current Enums can not migrate to be
value types:
1. enums have identity
2. enums have java.lang.Enum abstract class as super-class, not java.lang.Object
3. there is no clear default value
4. enums have mutable fields.

What I think you are wondering about is if there is a role for a new kind of 
type,
value-enums, that have value type characteristics. I totally agree with John
that the is a future exercise. And if you can figure out a migration story in
future, more power to you, but we are not designing value types around that
requirement.

A note - at least from the hotspot perspective, enums are not special-cased
and as you can imagine we are trying to minimize special cases since they
tend to be sources of bugs, so we would like to keep it that way.

thanks,
Karen

> On Feb 1, 2018, at 2:05 PM, John Rose  wrote:
> 
> On Feb 1, 2018, at 5:24 PM, Paul Sandoz  > wrote:
>> 
>> an enum class to also explicitly be a value class
> 
> Yes, it's probably doable, but we would have to work out the
> migration story, and also figure out how to manage the Enum
> supertype.  Remember that one of the ongoing challenges
> of VT's is the role of Object.  For value-enums, I think we
> would reprise the role for Enum.  I'd rather have template
> classes under my belt before tackling that, so I could make
> Enum behave differently as an object vs. a value supertype.
> 

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

[Paul Sandoz]

> On Feb 7, 2018, at 6:35 AM, Karen Kinnear  wrote:
> 
> Paul,
> 
> Just to make sure we are in sync for now:
> 

We are.


> I think we are all in agreement that current Enums can not migrate to be
> value types:
> 1. enums have identity
> 2. enums have java.lang.Enum abstract class as super-class, not 
> java.lang.Object
> 3. there is no clear default value
> 4. enums have mutable fields.
> 
> What I think you are wondering about is if there is a role for a new kind of 
> type,
> value-enums, that have value type characteristics.

Yes, it was a thought exercise which also conveniently pushed on some other 
areas like static fields.

Thanks,
Paul.

> I totally agree with John
> that the is a future exercise. And if you can figure out a migration story in
> future, more power to you, but we are not designing value types around that
> requirement.
> 
> A note - at least from the hotspot perspective, enums are not special-cased
> and as you can imagine we are trying to minimize special cases since they
> tend to be sources of bugs, so we would like to keep it that way.
> 
> thanks,
> Karen
> 
>> On Feb 1, 2018, at 2:05 PM, John Rose > > wrote:
>> 
>> On Feb 1, 2018, at 5:24 PM, Paul Sandoz > > wrote:
>>> 
>>> an enum class to also explicitly be a value class
>> 
>> Yes, it's probably doable, but we would have to work out the
>> migration story, and also figure out how to manage the Enum
>> supertype.  Remember that one of the ongoing challenges
>> of VT's is the role of Object.  For value-enums, I think we
>> would reprise the role for Enum.  I'd rather have template
>> classes under my belt before tackling that, so I could make
>> Enum behave differently as an object vs. a value supertype.
>> 
>