enhanced enums - back from the dead?

forax at univ-mlv.fr forax at univ-mlv.fr
Sat Dec 8 12:45:38 UTC 2018

----- 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 ?

> Maurizio


More information about the amber-spec-experts mailing list