Feedback on LazyConstants (formerly StableValues)

[Chen Liang]

Hi David,
From your description, I think in a factory method that reads the properties file, you can first read that path, then construct a LazyConstant that loads the CSV from that fixed path and parses the list and keep the LazyConstant in your configuration object. That way you can just ask the LazyConstant when you need this list of sensors.

Chen
________________________________
From: amber-dev <amber-dev-retn at openjdk.org> on behalf of david Grajales <david.1993grajales at gmail.com>
Sent: Wednesday, September 24, 2025 10:24 AM
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Cc: Per-Ake Minborg <per-ake.minborg at oracle.com>; amber-dev <amber-dev at openjdk.org>
Subject: Re: Feedback on LazyConstants (formerly StableValues)

I am not sure what you mean. but in my particular case the configuration class is a class that reads the fields of a properties file. this properties has a path to an CSV file with a list of IP addresses for IoT sensors and I use that path to fill a list of addresses to send and read some signals to the sensors. So I think both initialization processes can be lazy, even if one depends on another. I suppose that's what you mean by "known at construction time"?



El mié, 24 sept 2025 a la(s) 9:50 a.m., Maurizio Cimadamore (maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>) escribió:

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<mailto: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/7f053f03/attachment-0001.htm>