JEP 301: Enhanced Enums

[Maurizio Cimadamore]

For the records - here's a more complete example where lack of sharp 
typing hurts, I think:

http://hg.openjdk.java.net/valhalla/valhalla/langtools/file/ce7460995ffc/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Dynamic.java#l41

The enum defines all possible kinds of constants which can appear as 
static arguments in an invokedynamic call.

As you can see, many of the methods in this enum are 'partial': they 
only make sense for certain constants, but not for others. Currently, 
the only way around this, is to declare this method at the root (the 
enum itself), and then have the method throw some exception if it's not 
supposed to be implemented for certain constants. I believe this idiom 
is a red herring; you really don't want the asType/asSymbol be defined 
for a STRING constant - and if they weren't, you would get more static 
type checking back which would prevent you from calling methods that are 
not 'supported' rather than relying to a runtime check.

Maurizio


On 07/12/16 09:48, Maurizio Cimadamore wrote:
> Thanks for the feedback. I personally run into the lack of sharp 
> typing  several times and seen other people stumbling on it too.
>
> Do you have some example in mind that will break - other than the ones 
> listed in the JEP? In my mental model, the kind of surprises this 
> introduces are very similar to anonymous inner class types - that is:
>
> new Object() { void m() { } }.m();
>
> this is legal code because the receiver expression doesn't have type 
> Object - but has a sharper type (which can 'see' the additional 
> member). This proposal is about doing the same with enums - which 
> accidentally will sit well with adding generics (because in that case, 
> the constants will have a richer generic type than their parent).
>
> Maurizio
>
>
> On 07/12/16 09:03, Remi Forax wrote:
>> Now, If this proposal is accepted, at least, instead of changing the 
>> spec to introduce sharp types for all kind of enums, adding sharp 
>> type only for generics enums,
>> it will break no code because generics enum currently do not compile.
>