This as the drawback (real or hypothetical i don't know) to introduce an initialization dependency between the initialization of the enum (the initialization of its constants) and the initialization of the constant dynamic because at least for the first approach, you need to get the enum constant to get its class but that enum constant may not be initialized at the time the type is needed.
Rémi ----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Kevin Bourrillion" <kev...@google.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Mardi 18 Décembre 2018 18:27:13 > Objet: Re: enhanced enums - back from the dead? >> >> 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.
