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

[Brian Goetz]

Are there any downsides?  OMG yes.

The forms of constant expression that the JLS defines are all things 
that _the language can tell are constants just by looking at them_.  
String literals, numeric literals, combinations of the above with 
operators (e.g., 1+2), and the same laundered through #define-like 
variables (and even this is starting to skate towards the thin part of 
the ice.)

Whereas Enum.name() is an ordinary Java method.  So defining it as a 
constant expression is crossing an enormous line, because either (a) the 
language has to do some analysis to prove that the function body is pure 
(and even there, you have issues with separate compilation, which I'll 
ignore for now), or (b) the language has to believe some sort of "trust 
me bro" annotation that the function is safe to execute at compile time 
and cache the result without perturbing program semantics, not unlike 
`constexpr` in C++.   Both of these are significant language changes.

Suppose we thought they were valid (see the exploration in, e.g., my 
"Below the Fold" JVMLS talk from about 5-6 years ago).  Is this really 
about Enum::name?  Can you imagine how many thousands of RFEs would 
follow for "please add String::length to the list too"?  So now, instead 
of a handful of things that are *obviously constants* (literals) and 
some things that are one level of indirection away from that (e.g. 
Math.PI, which as mentioned is already bordering on dodgy), there are 
going to be thousands of methods that also get this treatment.  Are 
users supposed to keep this list in their heads?  What happens when 
something doesn't fold as the user expects it, because some method calls 
a non-foldable method (or calls it with non-foldable arguments or 
receiver) seventeen levels down in the call stack?

Again, this is doable (again: see my video), but it is no mere "why 
don't you just" exercise -- it is a major language feature, with an 
attendant libraries evolution and probably some tooling support too to 
debug the inevitable "Y U NOT FOLD" problems.

But it gets worse that that, because, as I suspected, your real goal was 
to expand the set of things you can put in annotations. And once you 
start to expand that, you start to run into the very ad-hoc way that 
annotations support a fixed number of types. Eventually you are going to 
ask me to put List.of(... constants ...) in an anno, for all the same 
arguments, but expanding the set of types here cuts through the 
classfile format, class loading and validation, language, compiler, and 
reflection (and likely requires adding new bootstraps as well) in a 
particularly messy way.







On 10/16/2024 8:09 PM, David Alayachew wrote:
> Hello Amber Dev Team,
>
> In Java 23 JLS 15.29, it says that a constant expression can only be 
> made up of primitive LITERALS, String LITERALS, a couple of 
> operations, and CONSTANT VARIABLES.
>
> The word LITERAL means that, for strings, I need to put in the full 
> double quotes (or triple double quotes for textblocks) in order to 
> qualify.
>
> And the word constant variable is defined in 4.12.4. "A constant 
> variable is a variable of primitive type or type String that is 
> initialized with a constant expression", which is what 15.29 is, 
> mentioned above.
>
> Now, to my question -- are there any downsides or obstacles to adding 
> Enum.name() to this list of constant expressions?
>
> Enum.name() is a final method, and we know for a fact that, if the 
> class compiles, then it ALWAYS outputs the same value. And therefore, 
> it seems like it aligns nicely with the goals and intents of constant 
> variables. Is there anything bad or wrong about adding enum.name 
> <http://enum.name>() to the list?
>
> I do see some ways that it would provide value, but for now, I just 
> want to get an idea of if it would be bad or wrong to do before seeing 
> if it is worth it at this point in time.
>
> Finally, apologies for not having done any preview feature testing 
> lately. I have been juggling personal and work emergencies nonstop. 
> Only recently had a chance to poke my head out from the bomb shelter, 
> and I'm probably going to jump back in shortly.
>
> Thank you for your time and help.
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241017/cc9024ef/attachment.htm>