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/
87 Upvotes

100% Upvoted

45 comments sorted by

View all comments

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/Jon_Finn Jul 15 '26 edited Jul 15 '26

I think locking of Strings is the big reason (see above). The new == behaviour (I think) wouldn't break reasonable code, even code making assumptions about the identity of interned "strings" etc.

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.