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

[Anatoly Kupriyanov]

Agree. Placing an executable code into annotations sounds quite wild. I
could not imagine how should stack trace look like... Or adding a break
point?.. debugger?
IDE refactorings? Code coverage tools?

Too much magic. No, thank you.

On Fri, 18 Oct 2024, 10:33 Remi Forax, <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Kasper Nielsen" <kasperni at gmail.com>
> *To: *"Archie Cobbs" <archie.cobbs at gmail.com>
> *Cc: *"David Alayachew" <davidalayachew at gmail.com>, "amber-dev" <
> amber-dev at openjdk.org>
> *Sent: *Thursday, October 17, 2024 5:08:38 PM
> *Subject: *Re: Are there any downsides if we add Enum.name() to the list
> of constant expressions in the JLS?
>
> Hi, I know this feature has been requested a number of times. But I want
> to add one more usecase. There is common pattern in many frameworks of
> specifying a factory class in an annotation a.la.
>
>  @SomeFrameworkAnnotation(factory = MyAppFactory.class)
>
> Unfortunately, this pattern requires some more effort, if you want to use
> it together with modules. Either you need to open the package or handoff a
> Lookup object to the framework in some way. While this isn't super
> complicated, it would ease the on-ramp if you could simply use
>
>  @SomeFrameworkAnnotation(factory = MyAppFactory::new)
>
>  I know this type of "annotation programming" aren't really used in the
> JDK, but in Java's wider ecosystem I see it a lot.
>
>
> And this is not necessary a good thing.
>
> With my teacher hat, using annotations for the configuration usually means
> that the configuration is scattered into several files and and which make
> it hard to find/understand, fixing configuration issues in student
> enterprisy code is a pain because of that.
>
> So i've no problem with annotations being used to specify additional
> semantics @Entity, @Transactional etc but using annotations for specifying
> configuration, for me, is a step too far.
>
>
>  Best, Kasper
>
>
> Rémi
>
>
>
>> Idea: What about allowing lambda values for Class-valued annotation
>> properties when the Class is a functional interface?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241018/db519091/attachment.htm>