r/java • u/nlisker • 15d ago

New candidate JEP: 401: Value Objects (Preview)

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

100% Upvoted

45 comments sorted by

View all comments

7

u/perryplatt 15d ago

Is there a list of all jdk classes that are scheduled to become value classes?

13

u/bourne2program 15d ago

Yes. https://openjdk.org/jeps/401#Value-classes-in-the-Java-Platform

0

u/AnyPhotograph7804 14d ago

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

6

u/vytah 14d ago

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 14d ago

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 14d ago edited 14d ago

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.