RFR: JEP 359-Records: reflection code

[Brian Goetz]

> The class ObjectMethods is in the package java.lang.invoke if you take a look to the source but in the package java.lang.runtime if you trust the webrev.
> 
> It should be in java.lang.invoke so Claes (or someone else) will be able to optimize it later, otherwise if we want to use an internal non public MethodHandle,
> we will have to rely on a special SharedSecret class.

No.  Going forward, _all_ language-support runtime is moving to java.lang.runtime.  We got where we are today honestly, first by putting LambdaMetafactory there, and then string concat, but going forward, JLI is not the place for the language support runtime, and we need to reverse this trend.  JLI is for the java.lang.invoke implementation.  We’re in the process of disentangling the dependence of LMF and string concat on JLI internals.  

> I propose the following design to fix these issues:
> All invokedynamic should takes the same constant dynamic as parameters typed as an Object.
> This object should be an instance of an internal class of ObjectMethods (let say RecordMirror) created or populated by the VM from the Record attribute, from inside the constant dynamic BSM, so there will be only one upcall and one downcall instead of one upcall per getter.

I think you’re suggesting something like:

    interface ObjectMethodsMirror {
        int numParams();
        String paramName(int n);
        MethodHandle paramAccessor(int n);
    }

or something similar?  And then some code to derive such a thing from a record?  I don’t intrinsically object to this approach, but I’m also not entirely convinced.

Don’t forget, this is not just for records.  Value types, and other language compilers that have similar mechanisms, may want to use this as well, so anything with “record” in the name is likely wrong.

> This class can store the property names using the StringConcatFactory format and all the getters (the constant method handles).

Aligning the name format is reasonable.

> So the bootstrap method is just:
>  public static Object bootstrap(Lookup lookup, String methodName, TypeDescriptor type, Object recordMirrorObject) 

BZZT, you used the R-word :)

If w’ere going this way, I would much prefer to use an interface.  Then we need a condy bootstrap to serve up the mirror … the sensible version of which, hmm, looks a lot like the current bootstrap….