Feedback on LazyConstant (previously StableValue)

[Maurizio Cimadamore]

Hi Mikhail,
you are correct LazyConstant aims at the 80% use case, which is more 
similar to Kotlin's "lazy" keyword.

As stated here:

https://mail.openjdk.org/pipermail/leyden-dev/2025-September/002712.html

 > That said, the quest for a more fundamental building block is not 
over: we now have a clearer idea on how to expose "stable" access to 
regular fields/array elements, using a _new_ var handle access mode. 
Initial experiments look indeed promising: such an approach doesn't 
require the allocation of intermediate abstractions, and allows clients 
to decide if they want to pay for synchronization or not.

In other words, something else (lower level) will appear at some point 
in the future to "complete" the API. I believe the VarHandle-based 
solution we're exploring should be an even better translation target for 
Kotlin, as with the outlined strategy you'd now be in control of whether 
you need non-plain access, synchronization, etc.

Maurizio


On 10/11/2025 15:51, Mikhail Vorobev wrote:
>
> Hello Amber Team,
>
> I write to provide a data point from the Kotlin Evolution Team on the 
> design of LazyConstant (previously StableValue). In Kotlin, there is a 
> `lateinit var` declaration for a variable that is in an uninitialized 
> state until it is assigned later during execution, after that it 
> behaves like a normal variable. In practice, people tend to use such 
> declarations primarily for variables with stable semantics, e.g. for 
> injected dependencies or Android View bindings:
>
>
>     class Application {
>
>         @Inject lateinit var service: Service
>
>     }
>
>
>     class MyActivity : AppCompatActivity() {
>
>         lateinit var view: ImageView
>
>         override fun onCreate(...) {
>
>             view = findViewById(R.id.image)
>
>         }
>
>     }
>
>
> These variables are intended to be initialized at most once and never 
> change after that. To cater to such use cases, we considered 
> introducing `lateinit val` declaration in some form (possibly just as 
> a delegate, similar to how lazy is implemented now in Kotlin).
>
>
> StableValue was a perfect fit for the implementation of `lateinit 
> val`. On the other hand, LazyConstant could not be used to express 
> desired semantics (without hacks) due to its limited API: it does not 
> allow setting the value directly after construction.
>
>
> From our point of view, the current LazyConstant API, in contrast to 
> StableValue, does not cover a considerable part of use cases for 
> variables with stable semantics where they are initialized from values 
> available later and there is no sensible initializer function that 
> could be provided beforehand.
>
> Best Regards, Mikhail Vorobev, Kotlin Evolution Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251110/35ebdf04/attachment.htm>