Draft JEP Announcement: "Computed Constants"

[John Rose]

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.