<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
I think this is pushing on the short end of the lever; it’s a heroic, narrow, brittle (expensive!) optimization for a narrow outcome. I have a hard time believing we would ever run out of opportunities to invest in higher-leverage activities.
<div class=""><br class="">
</div>
<div class="">This is, at root, a layout specialization problem, similar to specializing instantiated generic types such as Pair<int,int>; investing in that seems likely to be higher-leverage for the imaginable future.<br class="">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On May 20, 2025, at 12:28 AM, John Bossons <<a href="mailto:jbossons@gmail.com" class="">jbossons@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Looking for a way to avoid complicating the VM, suppose I rewrite the PostCodeCA class as follows:<br class="">
<br class="">
value class PostCodeCA {<br class="">
byte b0;<br class="">
... <br class="">
byte b5;<br class="">
PostCodeCA(String s) {<br class="">
byte[] asciiBytes = s.getBytes("US-ASCII");<br class="">
if (asciiBytes.length != 6) throw exception;<br class="">
// other validation code here<br class="">
b0 = asciiBytes[0];<br class="">
etc.<br class="">
}<br class="">
// equals, hashCode etc. based on b0 ... b5<br class="">
}<br class="">
<br class="">
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 class="">record</b> as a model) gets the compiler to generate detailed code such as the above from a specification like<br class="">
<br class="">
<b class=""> fixedSmallArray</b> PostCodeCA { byte[6] asciiBytes } // immutable array thanks to encapsulation<br class="">
<br class="">
Is this a workable idea? (Again, for the future, after value objects are delivered.) The key thought is that the compiler ought to be able to do this without requiring any more modification of the VM than was required for records.
<div class=""><br class="">
</div>
<div class="">It's immutable arrays through the back door.<br class="">
<div class=""><br class="">
</div>
</div>
</div>
<br class="">
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Mon, May 19, 2025 at 5:07 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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.
<br class="">
<br class="">
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.
<br class="">
<br class="">
> On May 19, 2025, at 4:23 PM, John Bossons <<a href="mailto:jbossons@gmail.com" target="_blank" class="">jbossons@gmail.com</a>> wrote:<br class="">
> <br class="">
> 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.<br class="">
> <br class="">
> 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.<br class="">
> <br class="">
> The compiler would need to verify that the field initialization is correct, but could this not be done by requiring<br class="">
> 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?<br class="">
> <br class="">
> John<br class="">
<br class="">
</blockquote>
</div>
<div class=""><br clear="all" class="">
</div>
<div class=""><br class="">
</div>
<span class="gmail_signature_prefix">-- </span><br class="">
<div dir="ltr" class="gmail_signature">
<div dir="ltr" class="">Phone: (416) 450-3584 (cell)</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>