The potential gain is the ability to store a string value, rather than a reference to a string. Same as the ability store a 2Dpoint as a value containing two numbers, rather than as a reference to the instance.
On Tue, Sep 1, 2026 at 5:20 PM Chen Liang <[email protected]> wrote: > 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) > -- Phone: (416) 450-3584 (cell)
