RFR: JDK-8282798 java.lang.runtime.Carrier

[John R Rose]

On Tue, 8 Mar 2022 15:59:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. 
>> 
>> See JBS for details.
>
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 48:
> 
>> 46: 
>> 47: /**
>> 48:  * This  class is used to create objects that have number and types of
> 
> The class javadoc seems a bit on the thin side. I would say something on the fact that the shape of the carrier is determined by a MethodType, etc, and add an example to illustrate basic usage.

Agreed.  Also, this class is unusual in that it is not instantiated; like `Arrays` or `Collections` it is a (small) bundle of static factories (or are they algorithms?).  I think as such it should be called `Carriers`.

I'm slightly surprised the MH factories are not factored through a metaobject of the form

record CarrierBinding(
    MethodType methodType,
    MethodHandle constructor,
    List<Class<?>> componentTypes,
    List<MethodHandle> components)
{ … }


The presupposition here, I suppose, is that carriers will only be used by condy or similar quasi-statically configured clients, so having the multiple lookups through a hidden table is no burden, and the clients can always keep the associations correct (between constructors and various component accessors).

**But** if I were to use carriers to manage intermediate structures in (say) a serialization package (for instance) I would need to make my own records like the above for my own bookkeeping, and I would be slightly miffed that the Carrier API insisted on doing a de-novo lookup twice on each MT key (to say nothing of me having to create the MT key first).

**And** if I were to use carriers in that way (away from condy), **then** I would want to skip the step of building the MethodType, and wish for a factory method for CarrierBinding instances that took a plain List<Class>, as well as a factory method that took the MethodType (which is convenient for condy).

BTW, it would be normal to give the name `Carrier` (which is a good name BTW) to the record type that embodies the group of method handles, so `record Carrier(…constructor…components…) {…factories…}`.

I suppose stuff like this could be added later.  But it's worth considering now, simply because there is an early decision point between a class named `Carrier` and a static-only class named `Carriers`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7744