[records] spec clarifications from thread in amber-spec-experts
brian.goetz at oracle.com
Thu Jan 30 15:40:26 UTC 2020
On 1/29/2020 11:36 PM, John Rose wrote:
> Working with Brian, I updated this some more:
> 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.
>> I’ve rebased the webrev to the current tip:
>> Shall I push this, or will someone else do so?
>> — John
More information about the amber-dev