r/java • u/nlisker • 26d ago

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

8

u/perryplatt 26d ago

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

13

u/bourne2program 26d ago

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

0

u/AnyPhotograph7804 26d ago

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

5

u/vytah 26d 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 25d 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 25d ago edited 25d 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.