Sorry, I've seen discussions here and there from random commentors about this, but I certainly wasn't party to any involving you or the OpenJDK folks. But I do see that you've answered this question at least 3 times on reddit, searching your comments on Reddit. I tried a google search and a mailing list search [1] before this, which turned up nothing. Guess I'll try a reddit specific search next time, which turns up a few results when I try that now.
Anyways, thanks for answering, I'm not trying to start a discussion, as much as understand what the quote meant. It makes much more sense now. [1] = https://openjdk.barlasgarden.com/?mode=text-search&q=String%20value%20class&order=relevance&limit=25 On Sat, Aug 29, 2026 at 12:45 PM Brian Goetz <[email protected]> wrote: > This one got discussed to death on Reddit, and I know you were there, so > not sure why we're restarting the discussion here, but... > > But in any case, to summarize (and at this point this is mostly > theoretical, since any action on this would be a while off): yes, in > theory, it is possible. The mutable state can move into the byte/character > array leaving String with a footprint of a single oop (which would have to > not be shared.) (The word "can" there is doing a lot of lifting.) There > would be a LOT of other work throughout the platform required to make it > possible, and for any perturbation to even some minor aspect of String > performance, there is some critical application that is highly tuned around > that assumption. > > The benefit of bringing the character data one hop closer to where it is > consumed is real. But the very large price tag (do you know how much code > there is in the VM to special-case String?) and the potential performance > regressions in corner cases (even if overall performance is improved) means > we would want to proceed with extreme caution here, and it is not anywhere > near the top of the priority list. > > On 8/29/2026 12:14 PM, David Alayachew wrote: > > Hello @valhalla-dev <[email protected]> <[email protected]>, > > I was just watching the Inside Java Podcast, episode 68, and at 16:35 [1], > they start talking about operator overloading, mentioning at 17:53 [2] that > String can't be a value class. > > I've heard bits and pieces of the why behind this claim, here and there, > something to do with hashCode. So, I looked at the source code for String > [3]. > > I see 2 mutable fields -- private int hash [4] and private boolean > hashIsZero [5]. But assuming that JEP 531: Lazy Constants (Third Preview) > [6] goes live, that should allow these 2 to be final fields. > > I know there are other things required to be a value class, but I don't see > where String would fail those pre-requisites. > > But let me first ask -- Is it true that String can't become a value class? > And if so, why not? > > Thank you for your time. > David Alayachew > > [1] = https://youtu.be/qGRAWfLLJFQ?si=vRZ_I_2BzRT0jh0D&t=995 > [2] = https://youtu.be/qGRAWfLLJFQ?si=2PrN0Af_vys1Jtif&t=1073 > [3] > =https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java > [4] > =https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java#L206 > [5] > =https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java#L214 > [6] = https://openjdk.org/jeps/531 > > >
