It is a base assumption that the specific representation — bits in an int[], a
class per shape, a cache of common shapes, etc — is a pure implementation
detail that can be changed at will, based on various tradeoffs like
footprint-vs-startup that can be made at any time. The only assumption is that
when you pass a shape to the constructor() method, the same (hidden)
representation will be used when you pass the same shape in the same JVM
invocation to the component() methods.
Having a List<MH> view fo the components may help because of the internal
@Stable annotation.
For pattern matching, we envision storing the accessor MHs in condy at the use
site. String templates probably has a different expected user model.
> On Mar 8, 2022, at 11:04 AM, Maurizio Cimadamore
> <mcimadam...@openjdk.java.net> wrote:
>
> On Tue, 8 Mar 2022 14:02:39 GMT, Jim Laskey <jlas...@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.
>
> Looks good.
> I've left some minor doc-related comments.
> When reading (as discussed online) I wondered if using Unsafe to access
> values inside a byte[] or Object[] would simplify the carrier implementation
> somehow.
>
> 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.
>
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 129:
>
>> 127:
>> 128: /**
>> 129: * Factory for array based carrier. Array wrapped in object to
>> provide
>
> I found this comment hard to parse - or unhelpful to understand how the
> factory really worked. IIUC, this factory captures all parameters into an
> Object[] (using a collector MH) and returns that Object[] (which acts as the
> carrier object). I'm not sure I see anything here that would prevent the user
> from building a carrier and casting to Object[] ?
>
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 432:
>
>> 430: * Construct a new object carrier class based on shape.
>> 431: *
>> 432: * @param carrierShape shape of carrier
>
> Suggestion:
>
> * @param carrierShape shape of carrier
>
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 633:
>
>> 631: * getter.
>> 632: *
>> 633: * @param i index of component to get
>
> Suggestion:
>
> * @param i index of component to get
>
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 656:
>
>> 654:
>> 655: /**
>> 656: * Find or create carrier class for a carrioer shape.
>
> Suggestion:
>
> * Find or create carrier class for a carrier shape.
>
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 852:
>
>> 850: * @throws IllegalArgumentException if number of component slots
>> exceeds maximum
>> 851: */
>> 852: public static MethodHandle constructor(MethodType methodType) {
>
> What happens to the methodType return type? (both here and in the components
> method). Should javadoc say anything?
>
> -------------
>
> Marked as reviewed by mcimadamore (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/7744
