enhanced enums - back from the dead?
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