Draft JEP Announcement: "Computed Constants"

[Remi Forax]

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Dan Heidinga" <heidinga at redhat.com>
> Cc: "Per-Ake Minborg" <per-ake.minborg at oracle.com>, "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Friday, July 28, 2023 8:35:30 PM
> Subject: Re: Draft JEP Announcement: "Computed Constants"

> On 28 Jul 2023, at 8:53, Dan Heidinga wrote:
> 
>> … users now need to
>> understand if the cost of the lambda generation (inflation?  Not sure what
>> the right term is for converting a lambda expression to a functional
>> interface instance) will be more or less than the cost of the computation
>> they want to store in a ComputedConstant if they want to realize a startup
>> benefit from this change.
> 
> Yes, this problem of scaling is raised by the very existence of a better
> alternative to <clinit>:  Can it beat <clinit> robustly or must it be used
> sparingly, because the language and VM don’t optimize it very well?
> 
> I would like to take CC’s as they are proposed here, and then expand their
> mission.  (…After some shallow name changes: package should be java.lang and
> s/ofList/list/ or s/ofList/of/.)
> 
> After that there are things we can do to reduce their footprint (in cycles and
> memory, and in user experience), so as to make them much more attractive as an
> everyday alternative to <clinit>-based fields.  Such “things” might be
> condensers (as Brian also mentions), or maybe language and JVM support.  In any
> case, the goal would be to help users make a clean escape from the clutches of
> <clinit>, for the sake of static tools.
> 
> This will be a followup exercise to CC’s.  I’ve written some thoughts about that
> here, FTR:
> 
> https://cr.openjdk.org/~jrose/leyden/after-computed-constants.html
> 
> In short:  I think the sweet spot for a condenser target here is not an array of
> MHs as Brian suggests, but rather a single static method with a string-switch,
> and a framework for invoking it reflectively from a public BSM of some sort.

I'm fine with a method <class-field-init> that takes an int (the index from the AutonomousValue attribute) and returns an Object to initialize each autonomous field at the first call. For me, there is no need for a BSM here.

Also I prefer the CC initialization semantics (the field initializer is only executed once) to the one you are using in your prototype, the field initializer can be called several times concurrently but only store the first value that complete.

Rémi