<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi wenshao,</p>
<p>I've written up a draft JEP for deprecating the disabling of
Compact Strings. There hasn't been a good term for running the
system with Compact Strings disabled, so I made up a term
"UTF-16-only" and used it here.<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8371379">https://openjdk.org/jeps/8371379</a></p>
<p>I also filed an enhancement to cover the change to add a warning
message when -XX:-CompactStrings is used, and I've assigned it to
you (wenshao). Not that this change can't be integrated until the
JEP is moved into the Targeted state.</p>
<p><a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8371431">https://bugs.openjdk.org/browse/JDK-8371431</a></p>
<p>You might want to associate PR 27995 with this bug report.</p>
<p>s'marks<br>
</p>
<div class="moz-cite-prefix">On 11/3/25 10:04 PM, Stuart Marks
wrote:<br>
</div>
<blockquote type="cite" cite="mid:09039475-af3e-43ed-8d6b-8e7678a2a053@oracle.com">
<p>Hi wenshao,</p>
<p>I think removing Compact Strings is a great idea! As you noted
in your first message, removing it would make String easier to
maintain. Just so that everybody here understands the issues,
every string algorithm has THREE implementations:</p>
<p>1. compact strings enabled, using ISO Latin 1 coder</p>
<p>2. compact strings enabled, using UTF-16 coder</p>
<p>3. compact strings disabled</p>
<p>In recent years I suspect our test coverage of the
compact-strings disabled case is lacking, as some bugs have
occurred in only that case. For example, see <a class="issue-link" data-issue-key="JDK-8321514" href="https://bugs.openjdk.org/browse/JDK-8321514" id="key-val" rel="5116378" moz-do-not-send="true">JDK-8321514</a>,
<a class="issue-link" data-issue-key="JDK-8316879" href="https://bugs.openjdk.org/browse/JDK-8316879" id="key-val" rel="5111011" moz-do-not-send="true">JDK-8316879</a>,
<a class="issue-link" data-issue-key="JDK-8360271" href="https://bugs.openjdk.org/browse/JDK-8360271" id="key-val" rel="5162410" moz-do-not-send="true">JDK-8360271</a>,
<a class="issue-link" data-issue-key="JDK-8360255" href="https://bugs.openjdk.org/browse/JDK-8360255" id="key-val" rel="5162395" moz-do-not-send="true">JDK-8360255</a>,
<a class="issue-link" data-issue-key="JDK-8221430" href="https://bugs.openjdk.org/browse/JDK-8221430" id="key-val" rel="4986621" moz-do-not-send="true">JDK-8221430</a>,
etc. (Some of these have been fixed, but some are still open.)</p>
<p>As Alan noted, however, we can't simply remove this case. We
also can't simply deprecate the command-line option; we need to
deprecate the feature of running without Compact Strings before
we can remove that feature.</p>
<p>Compact Strings were introduced with <a href="https://openjdk.org/jeps/254" moz-do-not-send="true">JEP
254</a>. The JEP doesn't mention that there is an option to
disable compact strings, but the <a href="https://docs.oracle.com/en/java/javase/25/vm/java-hotspot-virtual-machine-performance-enhancements.html#GUID-D2E3DC58-D18B-4A6C-8167-4A1DFB4888E4" moz-do-not-send="true">JVM Guide</a> describes the Compact
Strings feature and also the ability to disable it using the <font face="monospace">-XX:-CompactStrings</font> command line
option. This section doesn't say much about when you might want
to disable the feature, though; it merely says "This feature can
be disabled if you observe performance regression issues in an
application." Articles like this one from <a href="https://www.baeldung.com/java-9-compact-string" moz-do-not-send="true">Baeldung</a>, and vendor documentation
from <a href="https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-xx-compactstrings" moz-do-not-send="true">IBM</a> also document this option, but
they offer similarly vague advice.<br>
</p>
<p>Since the option is fairly well-known, it's not merely a matter
of looking at the status of the various ports (though those are
significant, of course). It could be that some installations out
there running with option to disable compact strings, perhaps if
they encountered a performance regression, or for other reasons.
They'll need to be informed that the feature is going away, and
the best way to do that is with a JEP.</p>
<p>There are some additional issues to consider as well.</p>
<ul>
<li>As Alan noted, the ARM32 port has compact strings disabled
by default. It's not clear whether it even works if compact
strings are enabled.</li>
<li>Compact strings increases storage requirements of CJK
character data. Our <i>assumption</i> has been that even
CJK-heavy applications use a lot of ASCII data for config
files, message headers, JSON, etc., and that compact strings
are still a net win for such applications. However, that's an
assumption. There's the possibility that some installation run
those applications with compact strings disabled.</li>
<li>The JNI <font face="monospace">GetStringCritical</font>
call returns a direct pointer in the non compact strings case
but makes a copy when compact strings are enabled. Some
applications may suffer regressions because of this; see this
<a href="https://stackoverflow.com/questions/76913323/string-compact-has-introduced-some-performance-issues-for-the-current-jni-how" moz-do-not-send="true">Stack Overflow</a> question.</li>
</ul>
<p>There are probably some other issues we haven't considered yet.
The best way to flush them out is to post a JEP, and then use
other channels to publicize the JEP. The JEP is mostly a
formality about changing the official status of running in the
compact-strings-disabled mode to "deprecated". Even though it
seems like a lot of overhead to write a JEP for this, the fact
is that many people in the tech press look only at the list of
JEPs for each release and not much else. Any many Java users
look only at tech publications to keep up with Java; they don't
look at GitHub or follow the OpenJDK mailing lists. Thus,
posting a JEP is the best chance we have to reach a broad set of
Java users, some of whom might be affected by this change.<br>
</p>
<p>Actual changes that go along with the deprecation will probably
only involve adding warning messages and possibly updating
documentation. We don't need to resolve issues like the ARM32
port yet. However, that will need to be resolved before we
actually remove the feature.</p>
<p>Since I'm "Dr Deprecator" I'll volunteer to draft the JEP.</p>
<p>s'marks<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/27/25 11:56 PM, Alan Bateman
wrote:<br>
</div>
<blockquote type="cite" cite="mid:d26f06b5-cc53-4ec4-97bd-69eb9944f779@oracle.com">
<div class="moz-cite-prefix">On 28/10/2025 06:32, wenshao wrote:<br>
</div>
<blockquote type="cite" cite="mid:08d048b2-5eb1-4db1-a169-a45e9f617b62.shaojin.wensj@alibaba-inc.com">
<div class="__aliyun_email_body_block">
<div style="font-family: Tahoma, Arial, STHeitiSC-Light, SimSun">
<div style="clear: both; font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span style="font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><br>
</span></div>
<div style="clear: both; font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span style="font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span>Thanks
to Alan for your feedback. </span></span></div>
<div style="clear: both; font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span style="font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span><br>
</span></span></div>
<div style="clear: both; font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span style="font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span>Based
on Chen Liang's suggestion, I submitted a new draft
PR <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27995__;!!ACWV5N9M2RV99hQ!OKe3zURFdlME6esFh_Travsoq4L0s3h71P8bsjCEG5RrmA0nzVmARS7ZAmOZEL0-DWdIg9P8orcXs26SZtYD-c8ZB8h_Fg$" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jdk/pull/27995</a>
to add a warning message to the ComactStrings
option. </span></span></div>
</div>
</div>
</blockquote>
<div class="__aliyun_email_body_block">
<div style="font-family: Tahoma, Arial, STHeitiSC-Light, SimSun"><br>
I think first step has to be establish what or who might be
using -XX:-CompactStrings in 2025. This means looking into
the status of ports. Andrew Haley is going to check with
folks in IBM as some of the bug reports for the
-CompactString code paths come from ports there.<br>
</div>
</div>
<br>
-Alan<br>
</blockquote>
</blockquote>
</body>
</html>