hg: valhalla/valhalla/langtools: Values types must be "all final".
rsteiger at ensemblesoft.net
Thu Jul 31 04:19:33 UTC 2014
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
>> 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
More information about the valhalla-dev