enhanced enums - back from the dead?

[Maurizio Cimadamore]

Sorrt for the very late reply - yesterday I was writing this, but got 
hijacked by Xmas party :-)


On 12/12/2018 16:40, Kevin Bourrillion wrote:
> What proportion of enum use cases benefit from this? Offhand, I would 
> have to guess that it is less than 0.1% (and if it turned out to be 
> /far/ less it wouldn't /shock/ me). Does anyone believe it's /likely 
> enough/ to be >0.1% that it's worth my effort to try to research that 
> question in our codebase (which would take a bit of work)?

Yes, this is THE question, but it is also a very tough one. I don't 
think this is one of those cases where one can write some kind of 
automated 'finder' which will tell you how often a given feature can be 
used in an existing code base; we were able to do that for 'var', for 
diamond, for lambdas. This is something very different, because looking 
for it essentially means looking for 'near misses' where maybe authors 
wished they had generics back when they wrote the enum, but they had to 
settle for some compromise.

Example:

http://hg.openjdk.java.net/jdk/jdk/file/24525070d934/src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java

And this falls into the 'easy' category - after all, this is still an 
enum, so it can be searched for. But how do we find the _classes_ that 
*could* be enums, but aren't simply because they are using generics (the 
same applies for other features not readily available in enums, e.g. 
local enums)? These cases are much more difficult (if not impossible) to 
spot!

Other instance that I found in the JDK codebase is that of enums which 
accept some 'stringified' key - e.g. something like this:

hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/sun/security/rsa/RSAUtil.java

I'm not an expert of this specific piece of code, but as in the Option 
enum experimement I did with javac, I believe that eager stringification 
is something that in principle could be cured by having more 
expressiveness in the enum declaration (e.g. have the key be a class, 
not a string!)


So I think this feature is, as Brian says, about removing unnecessary 
discrepancies between classes and enums - discrepancies that, in the 
past, might have tilted code one way or another; it might be hard now to 
evaluate precisely how much code has been tilted - within the JDK team, 
it looked as though many of us had this 'moment' where we wished that 
something like this was indeed possible.

Maurizio