RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview) [v19]

[Per Minborg]

On Fri, 17 Oct 2025 14:58:44 GMT, Per Minborg <pminborg at openjdk.org> 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 at 5ed828d[computing function = $Lambda/0x00000ffe000d6550 at 4d3167f4]  // Uninitialized
java.lang.LazyConstant at 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