On Tue, 8 Mar 2022 15:59:59 GMT, Maurizio Cimadamore <mcimadam...@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
