enhanced enums - back from the dead?

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Dec 5 16:14:59 UTC 2018

as mentioned in [1], the work on enhanced enum stopped while ago as we 
have found some interoperability issues between generic enums and 
standard enum APIs such as EnumSet/EnumMap.

Recently, we have discussed a possible approach that might get us out of 
the woods, which is described in greater details here:


We have done some internal testing to convince ourselves that, from an 
operational perspective, where we end up is indeed good. Some external 
validation might also be very helpful, which is why we're also in the 
process of releasing the internal patch we have tested internally in the 
'enhanced-enums' amber branch (we'll need to polish it a little :-)).

Assuming that, usability-wise, our story ticks all the boxes, I think it 
might be worth discussing a few points:

* Do we still like the features described in JEP 301, from an 
expressiveness point of view?

* Both features described in JEP 301 require some sort of massaging. On 
the one hand sharper typing of enum constants has to take care of binary 
compatibility of enum constant subclasses into account (for this reason 
we redefine accessibility of said subclasses along with their binary 
names). On the other hand, with the newly proposed approach, generic 
enums also need some language aid (treatment of raw enum constants 
supertypes). Do we feel that the steps needed in order to accommodate 
these sharp edges are worth the increase in expressive power delivered 
by JEP 301?

* Our proposed treatment for generic enums raises an additional, more 
philosophical, question: what are raw types *for* and how happy are we 
in seeing more of them (in the form of raw enum types)?


[1] - 

More information about the amber-spec-experts mailing list