Changing the bootstrap protocol of ObjectMethods

[Brian Goetz]

At the time, I recall asking "But, what is the point?  What problem are 
you actually trying to solve?"  I am still hazy on this.  There's 
nothing _wrong_ with the design you're suggesting, but I am having a 
hard time seeing how it is better, or that there's something wrong with 
what we've got that needs changing.

> This changes
> - separate the API for the record used by javac from the implementation of equals/hashCode and toString allowing other JVM languages to reuse the implementation even for classes that are non record

I still don't see the problem.  For a non-record class, there is still, 
abstractly, a set of "state variables"; they can each be accessed with a 
method handle (field accessor, getter method, etc), and they each have a 
name that will be used in the toString.  How is the current bootstrap 
unsuitable for non-record classes?  With the current bootstrap, it is 
equally useful to records and non-records alike, with no bias towards 
records.  Surely that is better than having two separate bootstraps, one 
for records and one for everyone else?

>    - for that a new class RecordLikeMirror is introduced as an abstraction on anything that defines components with a name and a type.

OK, another new abstraction.  What value does it serve?

>    - 3 new public API points are created, createEquals/createHashCode/createToString

This is a valid direction, but again I think it's unnecessary.  We have 
the the name/type channel in indy whether we use it or not; having three 
entry points which have to be separately specified and tested doesn't 
seem simpler than one.  Further, the current mechanism is extensible to 
other methods that can be generated from the same metadata (such as, 
perhaps, compareTo), whereas three separate bootstraps would not be.  
Yes, the equals/hashCode bootstrap could take one fewer parameter than 
toString, but even this is not a win -- because then the BMT entry can't 
be shared.

> - so now the method "bootstrap" can be specialized only for records and use reflection to extract the record components instead passing them as bootstrap arguments
That seems like a negative, not a positive?

Can we back up?  What problem are we solving?