enhanced enums - back from the dead?

[Maurizio Cimadamore]

On 08/12/2018 12:45, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> Envoyé: Samedi 8 Décembre 2018 00:57:58
>> Objet: Re: enhanced enums - back from the dead?
> [...]
>
>>> It's not that i don't like the feature, it's that for me it's a feature you can
>>> not even put in the box of the features that we could do. We start with "hey we
>>> could do this !" but there are some typing issues. Now, what your are saying is
>>> that we can use raw types to not have the typing issues, but as i said above,
>>> you are trading an error to a bunch of warnings, doesn't seems to be a good
>>> deal*.
>> I agree that having too many warnings is bad - in my experiment,
>> although I touched a lot of code, including stream chains, I did not
>> find them; Comparator.comparing is probably one of the worst beast (and
>> doesn't work well with target typing even beside generic enums). Not
>> sure if that shifts the balance one way or another, but point taken.
>>
>> On this topic, since I was there, I tried to tweak the prototype so that
>> Enum.values() and Enum.valueOf() return wildcards Foo<?>, but supertype
>> is Enum<Foo> and this seem to work surprisingly well, both in the tests
>> I had and in the new one you suggest. Maybe that would minimize the raw
>> type usage, pushing it quite behind the curtains, and strictly as a
>> migration aid for APIs such as EnumSet/Map ?
> Using Enum<Foo<?>> should also work ? no ?

No, we have tried that path and that doesn't work - ultimately you get 
an issue because EnumSet.of is accepting a Class<T>, and, in case of a 
class literal, you get back a Class<Foo> (Foo raw). So if supertype says 
Class<Foo<?>> you get two incompatible constraints on T, namely Foo and 
Foo<?>.

Maurizio

>
>> Maurizio
>>
> Rémi