[records] translation strategy

[John Rose]

7. Translation strategy.  (Is it polished and future-friendly?)  In the review
it’s done by means of jlr.ObjectMethods::bootstrap, which seems a little
non-specific to records.  Doing something with a simple-enough indy
(and no other javac-generated code!) is probably future-friendly.  When
and if we get “mindy” (indy-flavored method definitions) the indy instruction
can be quietly retired in favor of a mindy-bootstrap, with no semantic
change.  Beyond that, the happy point I want to get to in the future is a
sort of inherited mindy, where javac doesn’t mention “toString” at all
in any give record classfile, and instead there’s some wiring somewhere
that says, “records conform to Object via this mindy provider”.

That verges on an abstract class or even an interface; do we need or want
to add something like that as a mandated feature of all records?  Maybe
not.  But I do think we want to get a foot into the door somehow with
records, today, that we parley into a channel for new features tomorrow.

Actually, I’ll ask this another way:  Are we comfortable with saying that
records may in add new features in the future, without requiring opt-in?
Perhaps even without recompilation?  I think, “yes”, because the alternative
is that the features records have as of the first non-preview release is all
there will ever be.

In any case, that calls the question of how we prepare for this.  Choices:

A. Specify a super type now, and add the new API connection points to
the super type.  It could be an interface or an abstract class.

B. Have the JVM inject a super-interface later, when we figure out we
want new API points.

C. Use some ad hoc “code spinning” technique, without appealing to
inheritance.  When there’s an indy to spin from, great, but otherwise
do it at arms’ length.

A. is cleanest but maybe we can’t decide how to deploy inheritance here.
B. has one very bad bit of special pleading followed by inheritance later.
C. is all special pleading.

Suppose we add a new kind of serialization to records later on, and we
don’t want to require an opt-in or even a recompile.  It looks like this,
then:

A. Add necessary API points to the record super, and do code spinning
behind the scenes as an optimization.  New records can override the
new API points to get fuller control over the new feature.
A2. Optionally have compilers insert indy points for easier memoization
of spun code.  But don’t require them, for the sake of old code.

B. Same as A if the JVM has started injecting the record super.  Otherwise
same as C.

C. For the necessary new customized API points, do the code spinning and
caching in a set of static methods and a static table (or the ClassValue API).
C2. Use reflection to look for “opt in” quasi-overrides in each record, to
give back some control to the user.

When I say “code spinning” I mean any kind of ad hoc compiler-like
code generation, to bytecodes, to method handles, or to something else.

That “something else” might eventually be template methods; seems like
a possible story for us; it works in C++.