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

[Remi Forax]

> 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 [ http://a.la/ | 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/276c43ac/attachment.htm>