<story><title>Breaking java.lang.String</title><url>https://wouter.coekaerts.be/2023/breaking-string</url></story><parent_chain><item><author>gizmo686</author><text>Is this actually a bug? The default assumption in Java is that types are not thread-safe unless otherwise specified. Attempting to use types in a way that exceeds their documented thread safety has always been allowed to leave your program in an inconsistent state.</text></item></parent_chain><comment><author>coekie</author><text>Author of the blog here.
Yes, this is a bug. While the javadoc doesn&amp;#x27;t state it explicitly, immutable classes in the core library are expected to be thread safe. Java tries to be and mostly succeeds at being a safe language, where (by default) the guarantees of its internals cannot be broken no matter what user code does. The JVM preserves its own integrity.&lt;p&gt;There are some other deliberate holes in that safety, such as using reflection to access private members, and instrumentation, where it is clear you are stepping outside the safety zone, but even that is getting locked down now with the &amp;quot;Integrity and Strong Encapsulation&amp;quot; effort &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;openjdk.org&amp;#x2F;jeps&amp;#x2F;8305968&quot; rel=&quot;nofollow noreferrer&quot;&gt;https:&amp;#x2F;&amp;#x2F;openjdk.org&amp;#x2F;jeps&amp;#x2F;8305968&lt;/a&gt; .&lt;p&gt;In general, most code we write would not (and should not) try to protect against such abuse, but classes in the core platform play by different rules.&lt;p&gt;Btw, this has been accepted into the bug database now: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;bugs.java.com&amp;#x2F;bugdatabase&amp;#x2F;view_bug?bug_id=JDK-8311906&quot; rel=&quot;nofollow noreferrer&quot;&gt;https:&amp;#x2F;&amp;#x2F;bugs.java.com&amp;#x2F;bugdatabase&amp;#x2F;view_bug?bug_id=JDK-831190...&lt;/a&gt; . I expect this to be fixed in a future release.</text></comment>
<story><title>Breaking java.lang.String</title><url>https://wouter.coekaerts.be/2023/breaking-string</url></story><parent_chain><item><author>gizmo686</author><text>Is this actually a bug? The default assumption in Java is that types are not thread-safe unless otherwise specified. Attempting to use types in a way that exceeds their documented thread safety has always been allowed to leave your program in an inconsistent state.</text></item></parent_chain><comment><author>jillesvangurp</author><text>Not really. I&amp;#x27;m sure there are some edge cases where the ability for someone to do silly things like this is harmful but otherwise this goes in category of things where the general advice is &amp;quot;just don&amp;#x27;t do that and you&amp;#x27;re fine&amp;quot;.&lt;p&gt;Basically, if you look at why the standard library would not go out of its way to prevent you from doing stuff like this it boils down to the same reason as why they put the string compression optimization in to begin with: doing so would make things slower rather than faster. And that&amp;#x27;s just not desirable in something as performance critical as string initialization, which is a thing that a lot of Java programs would do a lot.&lt;p&gt;Having string compression helps save some memory but it&amp;#x27;s a weird low level hack. It&amp;#x27;s fine as long as you don&amp;#x27;t actively try to break things in your own program. You&amp;#x27;d have to jump through some hoops to do it accidentally. That is not likely to happen just like that.&lt;p&gt;So, not a bug but a known limitation that you should be aware of if you go down the path of doing lots of concurrent modifications to arrays that may or may not be used to create Strings. Java has lots of nice primitives and frameworks to make writing such code less error prone but it&amp;#x27;s up to you to use those properly and it&amp;#x27;s entirely possible to write all sorts of code that has lots of concurrency issues.</text></comment>