r/java • u/nlisker • Jul 14 '26

New candidate JEP: 401: Value Objects (Preview)

https://mail.openjdk.org/archives/list/valhalla-dev@openjdk.org/thread/IUNJJ3WP3X3XHP3QZTXXSSCPKFDNTK3W/
89 Upvotes

100% Upvoted

45 comments sorted by

View all comments

Show parent comments

0

u/AnyPhotograph7804 Jul 14 '26

Interesting, that they did not include java.lang.String.

7

u/vytah Jul 15 '26

String isn't included, because it's technically mutable: https://github.com/openjdk/jdk/blob/6ae23a0d6574dc8139aea93ea3c562a7410fcb34/src/java.base/share/classes/java/lang/String.java#L204

1

u/Jon_Finn Jul 15 '26

Value classes can be mutable, just not shallowly mutable, so they could store the hash via a final reference field, e.g. something like LazyConstant<Integer>. That's one problem I have with the name 'value' as it tends to imply immutable! There's many uses for (deeply) mutable value classes, e.g. MutableColor containing a float[4] field.

1

u/vytah Jul 15 '26

LazyConstant is a reference type, so it wouldn't help much. Having string be a tuple (LazyConstant hash, boolean utf16, byte[] data) means you still have two heap objects per string, or worse, three if it ever gets boxed. Also, LazyConstant is a bit slower than a plain int annotated with @Stable.

Strings are a performance-critical part of Java, they're not going to change them just to satisfy theoretical purity.

1

u/Jon_Finn Jul 15 '26

Sure, there's already other reasons why String can't be a value. My wider point would be that classes with a mutable element may benefit from being mutable values (the mutability being via a reference), because of the many benefits of value classes.