<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">Are there any downsides? OMG yes.
<br>
<br>
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.)<br>
<br>
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. <br>
<br>
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? <br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
<br>
<br>
<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 10/16/2024 8:09 PM, David Alayachew
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA9v-_M78VckRjENPDDs9OsN=f49KJkh8BwUOHyB2s3zmn5jBQ@mail.gmail.com">
<div dir="auto">Hello Amber Dev Team,
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Now, to my question -- are there any downsides
or obstacles to adding Enum.name() to this list of constant
expressions?</div>
<div dir="auto"><br>
</div>
<div dir="auto">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 <a href="http://enum.name" moz-do-not-send="true">enum.name</a>() to the list?</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div dir="auto">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.<br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thank you for your time and help.</div>
<div dir="auto">David Alayachew</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>