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)
