On Sat, 22 Jan 2022 19:29:45 GMT, Joe Darcy <da...@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
