[records] updates for Preview 9. hashCode
Brian Goetz
brian.goetz at oracle.com
Mon Jan 13 23:47:59 UTC 2020
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.goetz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200113/0b3712cb/attachment.htm>
More information about the amber-spec-experts
mailing list