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

[Clement Cherlin]

On Tue, Feb 24, 2026, 11:44 AM Kasper Nielsen <kasperni at gmail.com> wrote:

> Hi, This reads like a bunch of AI generated silliness. How on earth would
> you coordinate a 4 step migration process between a client and library,
> unless you strongly control both. /Kasper /Kasper On Tue, 24 Feb 2026 at
> 14: 16, Clement Cherlin
>
> Hi,
>
> This reads like a bunch of AI generated silliness.
>
> Please refrain from insulting your fellow contributors or their
contributions.

> How on earth would
> you coordinate a 4 step migration process between a client and
> library, unless you strongly control both.
>
> /Kasper
>
> You wouldn't; that's why it takes multiple steps. If you control both
client and library then it's a one-step process.

The purpose of the detailed multi-step migration plan is to answer the
concern that migrating a non-generic enum to a generic enum would be source
incompatible. Without tight coordination, it takes multiple incremental
steps to ensure source compatibility at each step.

It's the same process as deprecating an API. First you introduce the
replacement. Then you deprecate the old API. Then, after sufficient time
for clients to migrate, you remove the old API. You don't introduce the new
API and remove the old API in the same version, if you can avoid it.

Cheers,
Clement
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260224/8baed899/attachment.htm>