<div dir="ltr"><div dir="ltr">On Mon, May 19, 2025 at 11:28 PM John Bossons <<a href="mailto:jbossons@gmail.com">jbossons@gmail.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This works and can be flattened, but is rather ugly and laborious. So maybe I'm asking the question the wrong way. Maybe what I should be asking for is a subsequent JEP that (using <b>record</b> as a model) gets the compiler to generate detailed code such as the above from a specification like<br><br><b>    fixedSmallArray</b> PostCodeCA { byte[6] asciiBytes }     // immutable array thanks to encapsulation<br></div></blockquote><div><br></div><div>I had the same thought, but if this is your goal I see the implication differently: this is now "just" an optimization opportunity. You could write a bytecode transformation that looks for array fields that are private, final, non-escaping, never modified, and have a length known at compile time and automatically "inlines" them (surely such a thing already exists?). Or, the JVM could be enhanced to do this at runtime. Either way, there is no need any more for a JEP or language change.</div><div><br></div><div>-Archie</div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>