I will be more pessimistic than Brian.
String has a special status in the JLS, it's not a primitive type but at the
same time it has a lot of adhoc behaviors.
String is defined as an identity class with dictionary for constant Strings
(that you can access with .intern() as you said),
and the algorithm used for hashCode is also fully specified.
In terms of code, you have those strong requirements
(1) "foo" == "foo" // true
(2) new String("foo") == "foo" // false
(3) synchronized("lock") { } // stupid but should work
(4) "foo".hashCode() // 101574
Given the way value classes are currently defined, (2) and (3) are not possible,
so String can not be a value class without breaking backward compatibility.
regards,
Rémi
----- Original Message -----
> From: "David Alayachew" <[email protected]>
> To: "valhalla-dev" <[email protected]>
> Sent: Saturday, August 29, 2026 6:36:41 PM
> Subject: [SPAM] [External] : Re: Is it true that String can't become a value
> class? And if so, why not?
> And reading through JEP 401, it says that "The String class, due to some
> dependencies on object identity in its API and implementation, is not a
> value class, so instances of String are always identity objects".
>
> Assuming that the implementation dependencies are the hash and the boolean
> in my previous email, then that leaves API. The only thing I can see from
> the API that would do this would be the intern() method. Is that the API
> dependency that they are referencing? If so, how is it blocking String from
> being a value class? And if it is, is it truly insurmountable? Or are there
> thoughts about how to work around it? If so, would love to hear it.
>
> And finally, is this even worth doing? Meaning, is String better off being
> a reference type vs a value class, outstanding issues aside?
>
>
>
> On Sat, Aug 29, 2026 at 12:14 PM David Alayachew <[email protected]>
> 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
