RFR: 8351565: Implement JEP 502: Stable Values (Preview)

[John Rose]

> Are deeper cycles of concern? I was thinking of this:

There are a couple of ways existing java.util code handles
self-cycles.  The deepToString method handles them at all
levels, so it is robust.  But it is tricky and expensive.
(Look at the variable named “dejaVu”.)

If you grep for /"(this / in the java.util sources, you
will see several examples of a one-level exclusion of
self-references.  This is what the present PR emulates,
and I think it is just fine to follow those precedents.
It’s a 99% solution.  Omitting the self-check would be
a 90% solution, but the self-check is so simple that,
why not do it?  Adding a “dejaVu” table is not simple;
don’t.

One thing I noticed, when doing that grep, is that
the type name is usually “detuned”.  We should do that
as well in this patch.  For example, in Hashtable.java,
the string says “(this Map)” not “(this Hashtable)”.
The toString method tilts away from TMI. I think we
have a slight TMI problem in this patch, maybe, and
given the precedents I would expect “(this Function)”
not “(this StableEnumFunction)”, etc.

(TMI = Too Much Information.  See also Gafter on
the TMI temptation for language designers, which
applies to API design as well:
https://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html )

I see the PR’s unit tests look at this string.  My
humble take on it is, let’s dial back the TMI before
it’s too late.

(My sensitivity to TMI also informs other comments I
made on this PR.)