<div dir="ltr"><div dir="ltr">On Fri, Apr 11, 2025 at 10:50 AM Engebretson, John <<a href="mailto:jengebr@amazon.com">jengebr@amazon.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 class="msg8573172774682074737">





<div lang="EN-US">
<div class="m_8573172774682074737WordSection1">
<p class="MsoNormal" style="margin-left:0.5in">I would like to see JDK standard "array builders" for primitive types and reference types that use fixed sized (power-of-two) segments internally.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I want to caution on the power-of-two idea – it leads to large objects faster than the current implementation, which hurts performance as well as max capacity.  There is value in fixed-size options but we would want something with a slower
 rate of growth.</p></div></div></div></blockquote><div><br></div><div>Sorry if that wasn't clear - I didn't mean power-of-two exponential growth, I meant all segments were literally fixed size, like 256 or something (or maybe this value would be provided to the constructor). This keeps the access to individual elements constant time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg8573172774682074737"><div lang="EN-US"><div class="m_8573172774682074737WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">The "underlying problem" that I think should be addressed by some new internal class (or suite of classes) is the "array builder" problem. This is where you're doing "append, append, append, ..., use read-only thereafter".<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I would prefer targeting a few, common use cases – ByteArrayOutputStream is the example that got us here. Optimizing forward-only handling is an easy starting place and we can always add on later.</p></div></div></div></blockquote><div><br></div><div>Fair enough - my idea is independent in the sense that it could be done later and then retrofitted.</div></div><div><br></div><div>So I think I should probably go off and think about it more and stop hijacking your thread :)</div><div><br clear="all"></div><div>-Archie</div><div><br></div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div></div>