I think what you have in mind is something like a varchar - you might want a fixed-size buffer to represent a particular string, like using zero termination. I think you can already create such a custom CharSequence. However, I don't see how the lack of identity alone would be ever useful - you want optimized representation, which often means encoding the optimized length or character set in the type; unfortunately, any particular data structure would be too specific for a platform library. ________________________________ From: John Bossons <[email protected]> Sent: Saturday, August 29, 2026 1:44 PM To: Brian Goetz <[email protected]> Cc: valhalla-dev <[email protected]> Subject: Re: [External] : Is it true that String can't become a value class? And if so, why not?
That's why I suggested a *new special class* for a value object version of String. I think the backwards compatibility requirement absolutely rules out modifying the String class to be anything other than the identity class it is now. A new special class would be a new addition. It would not need to interoperate with existing code. It would only be used in new code where lack of identity could be useful. On Sat, Aug 29, 2026 at 2:36 PM Brian Goetz <[email protected]> wrote: > Strings are already unchangeable, so its not clear how the new abstraction > would differ, other than the lack of identity? (The fact that they are > implemented using a degree of mutation is an implementation detail, but > this mutability is not observable to the user.) And surely, the first > question everyone would ask is, "how does this new kind of string differ > from the String we already know?" > > In any case, a serious problem with this approach is that the type > `String` is embedded in literally every API in the ecosystem. So a new > type would not be able to interoperate with all the existing code. That > seems pretty bad. > > > > > On 8/29/2026 2:32 PM, John Bossons wrote: > > Might I suggest (as a followup project to JEP 401) that String not be > changed (too many ramifications to be backwards compatible) but that it be > complemented by a new value class ('UnchangeableString' , > 'FixedLengthString', 'SmallString', > Might I suggest (as a followup project to JEP 401) that String *not* be > changed (too many ramifications to be backwards compatible) but that it be > complemented by a new value class ('UnchangeableString' , > 'FixedLengthString', 'SmallString', or some other appropriate descriptive > moniker). > > It would be exceedingly valuable to be able to specify small unchangeable > strings as instances of a class that can be stored as value objects. This > would have widespread applicability (e.g. alphanumeric postal codes or > product codes, address strings, etc.). > > John > > 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]>, >> > >> > 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 >> <https://urldefense.com/v3/__https://youtu.be/qGRAWfLLJFQ?si=vRZ_I_2BzRT0jh0D&t=995__;!!ACWV5N9M2RV99hQ!MPiJLLsCF4DFDhP5ECJX7ZSPKYcAorWLeyb12NaM7p7pwnYEqcpJ3ZqqZBkInMYdQJ48ImOYJ4bILjjnPw$> >> > [2] =https://youtu.be/qGRAWfLLJFQ?si=2PrN0Af_vys1Jtif&t=1073 >> <https://urldefense.com/v3/__https://youtu.be/qGRAWfLLJFQ?si=2PrN0Af_vys1Jtif&t=1073__;!!ACWV5N9M2RV99hQ!MPiJLLsCF4DFDhP5ECJX7ZSPKYcAorWLeyb12NaM7p7pwnYEqcpJ3ZqqZBkInMYdQJ48ImOYJ4bWL2nMyA$> >> > [3] = >> > >> https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java >> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java__;!!ACWV5N9M2RV99hQ!MPiJLLsCF4DFDhP5ECJX7ZSPKYcAorWLeyb12NaM7p7pwnYEqcpJ3ZqqZBkInMYdQJ48ImOYJ4Z98FtjLw$> >> > [4] = >> > >> https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java#L206 >> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java*L206__;Iw!!ACWV5N9M2RV99hQ!MPiJLLsCF4DFDhP5ECJX7ZSPKYcAorWLeyb12NaM7p7pwnYEqcpJ3ZqqZBkInMYdQJ48ImOYJ4ar_Q_O0w$> >> > [5] = >> > >> https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java#L214 >> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/5962d86603a98a0f83aad6fcd6e9dcf90182504e/src/java.base/share/classes/java/lang/String.java*L214__;Iw!!ACWV5N9M2RV99hQ!MPiJLLsCF4DFDhP5ECJX7ZSPKYcAorWLeyb12NaM7p7pwnYEqcpJ3ZqqZBkInMYdQJ48ImOYJ4Z_wDfEiw$> >> > [6] =https://openjdk.org/jeps/531 >> > > > -- > Phone: (416) 450-3584 (cell) > > > -- Phone: (416) 450-3584 (cell)
