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

[John Rose]

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