Array fields in value objects

[Brian Goetz]

Except that object layout time is way too early for the JVM to figure out that “no one could possibly write to this.”  The JVM makes layout decisions on the basis of what is evident in the class file — ACC bits on fields, field descriptors, attributes on fields.  

If you recall, the descriptor type system is quite limited: carriers for the primitive types (I, J, F, D, etc), carrier for OOPs (Ljava/lang/String), and arrays of one of these types (e.g., [I, [[LString;, etc.). We would have to cram both finality _of elements_ and array size into one of the above channels, and at this point we’re describing a different virtual machine.  

> On May 19, 2025, at 4:23 PM, John Bossons <jbossons at gmail.com> wrote:
> 
> That's why I encapsulated the char[6] array in the PostCodeCA class. The immutability is a consequence of the array field being private and final, so that part should be easy to handle. I don't know how it could easily be accomplished other than through encapsulation.
> 
> With respect to fixing the size, could that be handled by providing an additional term to the field declaration (e.g. "fixed", as in "fixed char[6] codeValue", or even by just "char[6]" without the"fixed")?  That would mean the JVM only needs a single tag to know that the field is special and therefore possible to flatten.
> 
> The compiler would need to verify that the field initialization is correct, but could this not be done by requiring
> consistency between the field specification and the array constructor size parameter -- or for strings requiring use of a new toCharArray(int size) method? All the compiler needs to do is to check that the constructor/method parameter matches the field specification. Even if this were only done for primitives it would be very useful. Could a limited circumscribed version of this not be done as a "small" lift?
> 
> John