enhanced enums - back from the dead?

Brian Goetz brian.goetz at oracle.com
Tue Dec 18 17:27:13 UTC 2018

> In this feature, there are two changes (that we know of so far) that 
> might cause such observable effects.
> 1.  Not erasing the type parameter of Enum when computing the super 
> type of a raw enum type.
> 2.  Changing the translation of enum constants.  Right now, if you 
> have an enum constant that has a body, it gets translated as an inner 
> class, Foo$1.  We would probably change that to a named nested class, 
> such as Foo$A.

In the compiler meeting today, we realized there was another approach 
for (2), which was, rather than changing the declaration of the enum 
constant from Foo$1 to Foo$A, to instead use condy at the use site (go 
through something like ConstantBootstraps::enumConstant) to come up with 
the cast target for the cases where a client needs access to a member of 
an enum constant that is not inherited from a supertype (which isn't the 
common case.)  This would allow us to leave the translation of the 
declaration of enums alone, and instead perturb the use site, when the 
new behavior is needed.  Which removes one of our risk items.

More information about the amber-spec-experts mailing list