[records] updates for Preview 9. hashCode

[Brian Goetz]

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>