RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v8]

[Per Minborg]

On Mon, 31 Mar 2025 14:03:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > I have rewritten all the `toString()` methods. A `StableList::toString` now produces something much more similar to a regular `List::toString`. The only difference is that the `StableList::toString` shows ".unset" for the elements that are not yet evaluated. In other words, `StableList::toString` no longer evaluates all the elements, but rather does a "high impedance" scan over them and if evaluated, invokes `toString` on the element, otherwise just shows ".unset" for that element.
> > The same goes for `StableMap` and all the stable functions (which now share the same code path as the stable collections).
> > `StableValue` itself does not add extra square brackets around its content.
> 
> This seems fine -- I noticed that `toString` doesn't appear anywhere in the `Collection` API -- so there doesn't seem to be any contract for `List::toString` to behave in the way a list created with `List::of` does. I suppose I'm still not super convinced as to whether the fact that the list is backed by stable holders should be reflected in the `toString` or not -- after all, `toString` can be thought of as a method that depends on the element values, which would trigger materialization for said values. In other words, I'm not sure I get the precise use case where having such a method would be useful.
> 
> E.g. if I'm debugging, do I care whether I'm triggering evaluation earlier than normal? Is the worry that, by performing such an early evaluation, the resulting value for the element might be different from the one that would be triggered during normal execution (e.g. because of some stateful behavior in the function that computes the elements of the stable function) ?

As you mentioned, from a formal perspective, we are free to choose if `toString()` should evaluate the elements or not. The feedback I've got is that folks might use a debugger and then by merely observing a stable list (for example by automatic rendering in the source code made by IntelliJ and similar IDEs) the list would be fully evaluated. This makes the list behave differently if run normally compared to being run in a debug session. So, I think the current "high impedance" strategy is motivated. The downside is a bit more complex code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2766493534