On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <[email protected]> wrote:
> Implement JEP 526: Lazy Constants (Second Preview) > > The lazy list/map implementations are broken out from `ImmutableCollections` > to a separate class. > > The old benchmarks are not moved/renamed to allow comparison with previous > releases. > > `java.util.Optional` is updated so that its field is annotated with > `@Stable`. This is to allow `Optional` instances to be held in lazy > constants and still provide constant folding. > I’m gonna miss **Stable Values**, as it has some use cases which aren’t > served by **Lazy Constants**, and on which I depend on in some of my code, so > I’m stuck with using regular non‑`final` fields. > > Also, in the [JEP 526](https://openjdk.org/jeps/526) table under “[Flexible > initialization with lazy > constants](https://openjdk.org/jeps/526#Flexible-initialization-with-lazy-constants)”: > > > Update count > > Update location > > Constant folding? > > Concurrent updates? > > > > > > > > > > `final` field > > 1 > > Constructor or static initializer > > Yes > > No > > > > > > `LazyConstant` > > [0, 1] > > Anywhere > > Yes, after initialization > > Yes, by winner > > > > > > Non-`final` field > > [0, ∞) > > Anywhere > > No > > Yes > > The “Update location” of `LazyConstant` shouldn’t be “Anywhere”, as that was > only accurate for `StableValue`, but not for `LazyConstant`, which is updated > by calling the passed `Supplier`. > > Similarly, concurrent updates are prevented for `LazyConstant`s by using > `synchronized (this)`. I've updated the JEP. Thanks for pointing out this. Let me know what you think about the new text. We are exploring better ways to provide low-level, imperative, lazy constant/stable value fields. This work will be done outside the current JEP. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3396693041 PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3397160926
