[records] spec clarifications from thread in amber-spec-experts

[Brian Goetz]

+1.

On 1/29/2020 11:36 PM, John Rose wrote:
> Working with Brian, I updated this some more:
>    http://cr.openjdk.java.net/~jrose/draft/record-contract
>
> I think I’m done with it.
>
> I note that it will go into the next release, and requires a CSR.
> I’m grateful to Vicente for shepherding this.
>
> Another, deeper change that we should consider, in the
> next release, is to move the default logic for eq/hC/toS
> onto *concrete* methods on Record.  They would lazily
> spin the customized methods, and store them on a
> ClassValue, rather than require javac to put boilerplate
> into every record class file.  Doing this performantly
> might require some JIT work on ClassValue; in any
> case this is what ClassValue was designed for.
>
> FTR, I’m opposed to boilerplate in classfiles.  It never
> ages well.  I’m glad our current record translation strategy
> uses indy, delegating responsibility to the runtime rather
> than the static compiler for arranging the details.  But
> with the use of a ClassValue we can rely on standard
> inheritance from Record to define the method, instead
> of repeating a one-off “indy” incantation in each class file.
>
> — John
>
> On Jan 22, 2020, at 1:16 PM, John Rose <john.r.rose at oracle.com> wrote:
>> The spec-experts group seems to have reasonable consensus
>> on some clarifications to the javadoc in Record.java.
>>
>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001985.html
>>
>> I’ve rebased the webrev to the current tip:
>>
>> http://cr.openjdk.java.net/~jrose/draft/record-contract
>>
>> Shall I push this, or will someone else do so?
>>
>> — John