<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<blockquote type="cite" cite="mid:DM6PR10MB4283917B333E342C4930C620DA06A@DM6PR10MB4283.namprd10.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
I share your view that it is important to be able to use
ComputedConstant "early" in the VM startup sequence. There is
nothing inherent to the proposed API that *requires* a lambda or
a method reference to be used. An anonymous or regular class,
implementing Supplier would also do. Also, there is nothing
fundamental that prevents us from *implementing* the API in a
way it can be used "early".<br>
<br>
We do not add any keywords, the JEP is a pure library approach
so, I do not foresee any backward compatibility issues.</div>
</blockquote>
<br>
Allow me to translate ...<br>
<br>
Remi was assuming a goal. The problem is that he didn't state that
goal, or his assumption that this was a goal, before jumping to
criticizing your proposal. As a result, his criticism was unclear,
and IMO misplaced. <br>
<br>
The hidden goal that Remi was assuming is that "it should be
possible to migrate existing code that uses static final fields to
use computed constants in a source- and binary-compatible way."
Now, it should have been entirely clear from content that this was a
non-goal of this JEP (you didn't propose a language or VM solution,
and that was clearly deliberate), and if he wanted to express his
disappointment, he should have done so more directly, such as "I
wish there was a way to let old code play in this game." To which
the answer would have been "We may get there someday, some day, but
we're starting with something simpler."<br>
<br>
<br>
</body>
</html>