On Fri, 17 Oct 2025 14:58:44 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. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Update after doc comments After some discussion, we have concluded that we need to rework how `toString()` works for `LazyConstant`, lazy maps, and lists: #### For `LazyConstant` In order to align with other comput-later constructs like `Future`, we'd like to provide something like this: java.lang.LazyConstant@5ed828d[computing function = $Lambda/0x00000ffe000d6550@4d3167f4] // Uninitialized java.lang.LazyConstant@4ad92aa[42] // Initialized #### For lazy list, map, and all their derivatives (e.g., `subList()`, `values()`) There is a tension between the willingness to keep the `toString()` methods lazy during debugging and the compatibility with the existing `List` and `Map` implementations. It would be very surprising if a lazy list would output something different from a normal list for `toString()`. We think it is more important that lazy constructs are compatible with their corresponding eager constructs. Hence, we propose to make `toString()` trigger initialization of all elements/values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3441894953
