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 > > [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 > -- Phone: (416) 450-3584 (cell)
