Array fields in value objects

[Brian Goetz]

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> 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)