Overall this is good -- though I am not quite sure what the last bit
means here, about "derived from the behavior of Object::equals"?
122 * The precise algorithm used in the implicitly provided implementation
123 * is unspecified and is subject to change,
124 * within the limits of the contract of {@code Object.hashCode}
125 * as derived from the behavior of {@code Object.equals}.
On 1/13/2020 6:44 PM, John Rose wrote:
On Jan 10, 2020, at 1:20 PM, Brian Goetz <brian.go...@oracle.com> wrote:
No objection to further hashing the specification of the hash. Care to post a
proposed patch for the spec in j.l.Record?
Sure:
http://cr.openjdk.java.net/~jrose/draft/record-contract/
This fences out user assumptions about hashCode.
While I was at it I also did equals and toString.
The toString language is an example of applying similar
limitations. Probably it goes into too much detail; I added
it for the sake of discussion.
BTW, when designing the toString methods for MethodHandle
and MethodType we were ruthless about removing package
prefixes, and I’m glad we did it that way. Package prefixes
are noisy in toString output. I’m glad to see it going that
way with Record::toString also.
— John
