Feedback on LazyConstants (formerly StableValues)

[david Grajales]

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) 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) 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/adfb2c4f/attachment.htm>