Draft JEP Announcement: "Computed Constants"

[Maurizio Cimadamore]

Hi Remi,
I understand that the theme of static variables implemented via condy is 
dear to you.


That said, this attitude of immediately shooting out a counter-proposal 
5 minutes after seeing a JEP which originated after giving the very same 
topics you mention a considerable amount of thought, is (a) unfair and 
(b) has the net effect of sucking all the oxygen out this discussion.


Your comments are noted, now let's also make sure we hear what other 
people have to say.


Cheers
Maurizio


On 27/07/2023 18:03, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Goetz" <brian.goetz at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>, "Per-Ake Minborg"
>     <per-ake.minborg at oracle.com>
>     *Cc: *"leyden-dev" <leyden-dev at openjdk.org>, "John Rose"
>     <john.r.rose at oracle.com>
>     *Sent: *Thursday, July 27, 2023 6:23:01 PM
>     *Subject: *Re: Draft JEP Announcement: "Computed Constants"
>
>     As Maurizio said, this JEP is a refinement of ideas that were
>     initially explored in the "lazy statics" JEP.  In a way, this JEP
>     reveals the "lazy statics" JEP as skipping a step, jumping to a
>     language and VM when much of the benefit can be achieved by a
>     libraries approach.  It is possible that at some point, after
>     suitable progress and validation, we may decide to take the step
>     of pushing it further into the language/VM, but we've made the
>     deliberate choice to push such steps into the future.
>
>     In the meantime, there is no reason we cannot have multiple
>     "inconsistent" draft or candidate JEPs, so there is no need to
>     "merge" anything right now. 
>
>
> Here is my counter-proposal, use a @Lazy annotation to mark the static 
> final field and requires the static final fields to be initialized by 
> a static method.
>
> With the Logger example, it becomes
>
> class Bar {
>     // 1. Declare a computed constant value, it has to be initialized 
> by a static method
>     private static final @Lazy Logger LOGGER = initLogger();
>
>     // 2. Initialize the value
>     private static Logger initLogger() {
>        return Logger.getLogger("com.foo.Bar");
>     }
> }
>
> You have exactly the same information, it's easier for a class 
> rewriter than the computed constant proposal and a compiler guy and 
> then a VM guy can also work on it.
> And obvisouly, it's a backward compatible change.
>
> Rémi
>
>
>
>
>     On 7/27/2023 12:09 PM, Remi Forax wrote:
>
>         Hello,
>         Are you aware of the lazy static final fields proposal ?
>         https://bugs.openjdk.org/browse/JDK-8209964
>
>         In think both proposals should be merged.
>
>         Rémi
>
>         ------------------------------------------------------------------------
>
>             *From: *"Per-Ake Minborg" <per-ake.minborg at oracle.com>
>             *To: *"leyden-dev" <leyden-dev at openjdk.org>
>             *Sent: *Thursday, July 27, 2023 5:52:46 PM
>             *Subject: *Draft JEP Announcement: "Computed Constants"
>
>             Hi all,
>
>             Maurizio and I have drafted a JEP for computed constants,
>             which are
>             immutable value holders that are initialized at most
>             once.  They offer
>             the performance and safety benefits of final fields while
>             offering
>             greater flexibility as to the timing of initialization. 
>             In the
>             context of Leyden, they could be one basis for shifting
>             computation
>             both forward and backward in time.
>
>               The draft is here:https://openjdk.org/jeps/8312611
>             <https://openjdk.org/jeps/8312611>
>
>             Now that the Leyden repo is open, I’ll publish the
>             prototype code to a
>             new branch there shortly.
>
>               Comments are welcome!
>
>             Best, Per
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230727/5be840fc/attachment.htm>