RFR: JDK-8280168 Add Objects.toDefaultString [v6]

[Stuart Marks]

On Sat, 22 Jan 2022 19:29:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode.
>> 
>> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8280168
>  - Appease jcheck.
>  - Add toIdentityString
>  - Respond to review feedback to augment test.
>  - Respond to review feedback.
>  - JDK-8280168 Add Objects.toDefaultString

I'm wondering if we want to have `toDefaultString` at all, and whether we should have just `toIdentityString`. The primary use case, it seems to me, is the ability to get a string representation for some object, without involving any code in that object itself. There are the collections with cycles that I mentioned previously (in comments on the CSR), for which there is no well-defined hashCode. There is also the case that when logging mutable objects, the hashCode can change over time. This makes it difficult to analyze a log file and track what happens to a particular object. (I know I've been confused by this phenomenon in the past.) Thus `toDefaultString` doesn't seem all that useful to me.

It may be that the current use cases in the JDK can be replaced with `toDefaultString` but not `toIdentityString` without changing their behavior. But maybe we should consider changing their behavior and use `toIdentityString` instead.

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

PR: https://git.openjdk.java.net/jdk/pull/7139