Feedback on LazyConstants (formerly StableValues)

[Maurizio Cimadamore]

I see where you are headed.

The question now is: is the configuration known at construction, or is 
it only known when we call get() ?

If the former, then we can express it as a lazy field of some sort 
(perhaps one with a weird initialization action). But if the latter, 
that's no longer "just" a lazy field, I think. Would you agree?

Maurizio


On 24/09/2025 15:20, david Grajales wrote:
> Hi Maurizio and Minborg. Thank you so much for the response. I will 
> focus on explaining the part with the parameters for building objects. 
> This scenario is not as unique at it may seems, I used a singleton 
> because I thought it would be the easiest example but it's true it may 
> not be the most representative. I will hold my thoughts until I test 
> the new API. but I still would like to propose something. The supplier 
> based factory requires to capture a reference to an external variable 
> in case we need to set some parameters to create or compute the lazy 
> constant, which can't hurt performance a little if used often.
>
> var conf = "conf";
> var foo2 = LazyCosntant.get(() -> {
>     if (conf.isBlank()) {
>          // do some validations
>     }
>     return new Foo(conf);
> });
>
> I think it would be worth considering adding a function based factory 
> that accepts an object T (a configuration class to pass the 
> parameters), and a function that accepts the parameter and returns the 
> lazy computed value.
>
> private class Bar{
>    public final String confParam1;
>    public final int confParam2;
>    public Bar(String param1, int param2){
>       confParam1 = param1; confParam2 = param2;
>    }
> }
>
>
> var bar = new Bar("conf1", 42);
> var foo2 = LazyValue.get(bar, s -> {
>         if(/*Set some predicate for validation*/)  {
>          // do something
>     }
>     return new Foo(s);
> });
>
> I think it's cleaner and safer (also a little more performant since 
> the parameter can be inlined and not captured as an external element, 
> and since deferred initialization is pretty much about squeezing 
> performance it may be worth considering this). besides it may 
> internally check for T not null.
>
> Thank you so much and best regards.
>
>
>
> El mié, 24 sept 2025 a la(s) 7:02 a.m., Maurizio Cimadamore 
> (maurizio.cimadamore at oracle.com) escribió:
>
>
>     On 24/09/2025 11:38, Per-Ake Minborg wrote:
>     > I think the other examples you show (albeit I didn't fully get how
>     > they were supposed to work) would have issues regardless of whether
>     > there were language or library support for lazy computation
>
>     I'd like to amplify this point a little.
>
>     Your example shows the use of a singleton -- an object that is
>     constructed once, then stashed in a static final field.
>
>     However, the construction of the singleton (getInstance method)
>     depends
>     on a parameter.
>
>     This means that, effectively, getInstance will capture whatever
>     parameter value was passed the first time it was constructed.
>
>     Now, there might be use cases for this, but such a use case would
>     also
>     not be supported if using Kotlin's lazy, Scala's lazy val, or our
>     LazyConstant API (all of them are equivalent from an expressiveness
>     point of view).
>
>     So, your claim that
>
>     > this may indicate that a keyword or annotation-based solution
>     could be
>     > a better fit.
>     Feels a bit off -- either the example you provided is not what you
>     really had in mind, or, when you say _keyword_ you mean something
>     other
>     than a lazy-like keyword (but as Per explained, while there are some
>     more obscure keywords in other languages that might provide more
>     flexibility, the semantics associated with such keywords feels a bit
>     ad-hoc, and surely not something we would like to permanently bolt
>     onto
>     the language).
>
>     Cheers
>     Maurizio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250924/271f412a/attachment-0001.htm>