hg: valhalla/valhalla/langtools: Values types must be "all final".

[Richard Steiger]

I'm new to this list, so may well have missed previous discussions about 
the rationale for the "Value types must be all final" pronouncement.

While I'm not at all sure that value-type-finality is relevant to the 
following, I'd like to go on record stating that one of the more 
irritating aspects of the current enum semantics is the inability to 
extend an existing enum type with additional values.   I appreciate that 
there might be numerous subtleties that would need to be addressed in 
making enums "not quite final", i.e. extensible in a limited way (no 
overrides, etc.), the boon to application developers and others seems to 
me to justify at least thinking-through the issues.

On 7/30/2014 8:31 PM, Paul Benedict wrote:
> I've been thinking about this. When it comes to how enums were speced, they
> didn't need "final" or "class" specifiers (yes, an enum literal can be a
> subclass but ignore that for now). So I am not sure all these explicit
> qualifiers are helpful for writing value classes too. Granted, this is the
> straw man implementation, but I would like to hear anyone's thoughts on
> just making it "public value ClassName".
> On Jul 30, 2014 5:08 PM, <paul.govereau at oracle.com> wrote:
>
>> Changeset: ecff516ac894
>> Author:    pgovereau
>> Date:      2014-07-30 17:05 -0400
>> URL:
>> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/ecff516ac894
>>
>> Values types must be "all final".
>>
>> ! src/share/classes/com/sun/tools/javac/comp/TransValues.java
>> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
>> + test/tools/javac/diags/examples/ValueFinal.java
>> + test/tools/javac/valhalla/values/CheckFInal.out
>> + test/tools/javac/valhalla/values/CheckFinal.java
>> + test/tools/javac/valhalla/values/CheckFinal.out
>>
>>