<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 19/11/2025 08:35, Liam Miller-Cushon
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAL4Qsgut-oO54NyCdsvnFojtPNMd6Tj6m0WNsHP+onxmtjei4g@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Thanks Jorn, I took another pass over the PR and have
a draft of the changes you described: <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/28043__;!!ACWV5N9M2RV99hQ!LQ7S1ywQkPUR1HoloUuVqfMjlWNYy-pQfvF30QR2JcA47rfuO3DUYfk1y3AP6-KQ0p_OnW2Rdi9ReHM8y16tGA$" moz-do-not-send="true">https://github.com/openjdk/jdk/pull/28043</a></div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p><font face="monospace"> void copy(String src</font><font face="monospace">, Charset dstEncoding</font><font face="monospace">, int srcIndex, MemorySegment dst</font><font face="monospace">, int numChars</font><font face="monospace">);</font></p>
</blockquote>
<div>For copy, many of the other overloads have a
dstOffset as well. I suppose another overload could be
added for it later, or do we not want that here?</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
You are right, we need a (destination) offset parameter as well.<br>
<blockquote type="cite" cite="mid:CAL4Qsgut-oO54NyCdsvnFojtPNMd6Tj6m0WNsHP+onxmtjei4g@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>For encoding directly into a memory segment without
the need to go to an intermediate buffer, it looks
like we can use the internal StringCharBuffer class,
in combination with the `CharsetEncoder::encode`
method. But of course we can skip encoding
altogether when the internal string encoding matches
the target, and just do a bulk copy.</p>
</blockquote>
<div>Thanks, I got it working with
StringCharBuffer/CharsetEncoder::encode and did some
initial benchmarking. It is nice that it avoids the
copy, but the benchmarking suggests it's ~4x slower
than calling String#getBytes. I wonder if it makes
sense to use String#getBytes for now, and consider
future work to support encoding with substrings
directly to the destination with equivalent or better
performance than getBytes. What do you think?</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p>From some discussion offline, while the charset encoder API is
nice and abstract, is not always the most optimal. Your mileage
probably vary based on the length of the string to be encoded. I
think for now using getBytes (+ having a trick to avoid that if
the charset is compatible) should be good enough.</p>
<p>Maurizio<br>
</p>
</body>
</html>