Array fields in value objects

[Brian Goetz]

That would be a long way into the future :)

Right now, arrays are mutable.  So, with respect to value-ness, that’s game over.  But let’s say we had immutable arrays (which we surely would like to.). The next hurdle is representing the size in the runtime type system, because, to get flattening, we cannot be polymorphic in layout.  So the JVM would need to understand `final int[3]` as being a different, concrete, type than `final int[4]`.  Pushing dependent types into the descriptor and verifier type system is a big lift …

On May 19, 2025, at 3:00 PM, John Bossons <jbossons at gmail.com<mailto:jbossons at gmail.com>> wrote:

Thanks for the clarification.

Maybe this is a suggestion for a future JEP (flattening of immutable arrays)? Emphasis on "future".

John

On Mon, May 19, 2025 at 2:21 PM Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:
Arrays are always identity objects; JEP 401 will not change this.  PostCodeCA can be flattened into a single object reference, which is still plenty useful but it won’t flatten the underlying array.

> On May 19, 2025, at 2:15 PM, John Bossons <jbossons at gmail.com<mailto:jbossons at gmail.com>> wrote:
>
> The current version of JEP 401 describes the potential flattening of value object array elements, but leaves unspecified the treatment of value object fields that are themselves (immutable) arrays. Some questions:
>
> 1) Is a primitive array field (a field that is an array of primitives) necessarily accessed by reference (like an identity object) or can it be accessed as a bit vector (like a scalar primitive)?
> Example (fixed char array length):
> value class PostCodeCA {
>     char[] codeValue;  // 6-char code, Ascii letter/number chars, could store as byte[]
>     PostCodeCA(String s) {
>     codeValue = s.toCharArray();
>     // validation code, inter alia checks length == 6
>     }
>     ...  // Note that array elements are immutable because private
> }
> Can a PostCodeCA instance be stored as a bit vector, avoiding the indirection of a String reference?
>
> 2) Can the following be flattened (apart from the inescapable String ref)?
> value record AddressCA { String streetAddress, enum provCA, PostCodeCA zipCode }
> Note that use of the PostCodeCA class ensures the zipCode value is immutable.
>
> 3) Does it matter if an array field is of varying length?
> Example:
> value class CampaignArea {
>     int areaID;
>     PostCodeCA[] zipCodes;  // varying array length, again immutable because private
>     CampaignArea(int areaID, List<PostCodeCA> zipCodes) { ... }
>     ...
> }
> Does this class definition potentially permit flattening of a CampaignArea instance?
>
> This isn't just about strings, but they illustrate the issue as well as the potential. Also, it would be useful if this could be clarified in the JEP 401 text.
>
> John
>
> --
> Phone:  (416) 450-3584 (cell)



--
Phone:  (416) 450-3584 (cell)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250519/cf6ddd6c/attachment-0001.htm>