from computed constants to stable values

[Glavo]

Hi Maurizio,

It’s great to see Stable Values getting ready to start previewing, it’s a
very useful piece of work.
But I have doubts about some of the descriptions in the "Alternatives"
section.

In this section, the Class-holder idiom is described as "this makes
applications slower to start up".
But I don't find this convincing because all the previous examples are
using lambda,
and I believe that for the use case that is only called once, it has a
larger startup overhead than the holder class.

I've looked at the source code, so I know that StableValue has methods like
StableValue::trySet and StableValue::setOrThrow,
but I haven't seen them in the JEP draft. If they still exist today, can
they be included in the description of the JEP?
For use cases where startup time is critical, they should have lower
overhead than StableValue::orElseSet.

Glavo

On Thu, Jan 23, 2025 at 2:17 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi all,
> Per and I have been busy polishing the Computed Constant API. So much so
> that it has now changed name to Stable Value API :-)
>
> https://openjdk.org/jeps/502
>
> The goal is still to provide a safe API around JVM's @Stable value
> annotation. But, as we experimented with the old API, we realized that
> its "lambda-oriented" design, while good, was too restrictive when
> clients wanted to "set" the computed constant in a more imperative fashion.
>
> In the new Stable Value API, stable values are created unset. They can
> be set imperatively, or more functionally using a method similar to
> Map::computeIfAbsent. If you squint, the old computed constants have not
> disappeared: a computed constant can be expressed as a supplier that
> wraps a stable value -- we call such a supplier a "stable supplier".
>
> Per's talk at Devoxx 2024 is a good companion to the new JEP, with lots
> of interesting live examples:
>
> https://www.youtube.com/watch?v=3fXHrK3yV9w
>
> Let us know what you think!
>
> Cheers
> Maurizio
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250123/f96ff590/attachment.htm>