[External] : Re: Enhanced Enums Redux (with working code)

[Archie Cobbs]

On Tue, Feb 24, 2026 at 7:17 AM Clement Cherlin <ccherlin at gmail.com> wrote:

> On Mon, Feb 23, 2026 at 6: 26 AM Maurizio Cimadamore <maurizio. cimadamore@
> oracle. com> wrote: Hi Clement On 22/02/2026 18: 21, Clement Cherlin wrote:
> > Greetings, > > I have been working on the problem of generic enums off
> and on
> On Mon, Feb 23, 2026 at 6:26 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> > There is one slightly awkward issue. It's not possible to simply pass
>> > an enum class literal to EnumSet's static factory methods without a
>> > raw cast.
>> >
>> > EnumSet.allOf((Class<Option<?>>) (Class) Option.class);
>>
>> This makes me more worried -- because this is such a common idiom that
>> (I think) has to work like for any other enum.
>
>
> That's an excellent point. Doing the migration in a single step is source
> incompatible.
>
> However, it is possible to perform the migration in multiple steps...
>

I think that would be the wrong direction to take. The cost of dealing with
EnumSet.of() and friends should be measured in units of mental taxation,
not keystrokes.

We all agree that (Class<Option<?>>)(Class)Option.class is ugly from a
keystroke point of view, but that's not because Option is an enum, it's
because Java class literals are erased. In that respect, EnumSet.allOf() is
no different from any other method that takes a Class parameter.

So from a mental taxation point of view, having to do that cast adds no new
mental cost - Java developers already have baked into their brain when and
why you have to do it.

Speaking for myself as a developer, I would gladly pay the above keystroke
cost if that was all it took to allow enums to be generic. Surely there
must be a more compelling reason why we can't genericize enums...?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260224/12962b61/attachment-0001.htm>