Are there any downsides if we add Enum.name() to the list of constant expressions in the JLS?

[David Alayachew]

Thank you for your response Archie. This was exactly the type of response I
was looking for.

So, folks leaning on the fact that enum names are not constant might get
burned. I agree, these are oddballs. In fact, I would go further and call
this a misuse of the API, but if the line is "no breaking backwards
compatibility!", then I accept this as a dealbreaker.

As for the upsides, my personal use case is that I plan to use this for
annotations. There's a couple of benefits, like grouping relevant pieces of
information and methods together under the same enum value. Using
valueOf(), I can derive a lot of information back from it, allowing me to
add a whole bunch of information with a single source of truth. That has
been the cause of a lot of bugs for me lately, and the only way to achieve
something similar is to do something like nested classes or fake an enum.
Why not just use the real thing?

On Wed, Oct 16, 2024, 9:33 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Wed, Oct 16, 2024 at 8:33 PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> On Wed, Oct 16, 2024 at 7:09 PM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> Now, to my question -- are there any downsides or obstacles to adding
>>> Enum.name() to this list of constant expressions?
>>>
>>
>> Just to clarify, this could only work for enum constant literals, e.g.,
>> FOOBAR.name() which would obviously have value "foobar".
>>
>
> Oops, I meant "FOOBAR" ...
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241016/f0368c10/attachment.htm>