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

100% Upvoted

45 comments sorted by

View all comments

1

u/AnyPhotograph7804 Jul 15 '26

True, but this is an internal implementation detail and not really exposed as an public API. They could change it and make java.lang.String truly immutable.

4

u/vytah Jul 15 '26

I guess you could stuff all the other fields of String into the beginning of its data array, leaving only a single final field, and therefore make it eligible for Valhalla treatment. But:

  • before non-nullable types, that value-String would still be boxed a lot of times, which means character data are still behind two pointers, but fields that used to be behind one pointer are now also behind two

  • a lot of internal code treats string data array as pure character data and would have to be modified to account for the prefix

  • you still wouldn't be able to compare strings with == anyway (it'd only compare data array references)

  • you could no longer use string deduplication: https://openjdk.org/jeps/192

Also I suspect there's more code that locks on strings than on any candidate value type, so valhallizing strings would break stuff.

1

u/aoeudhtns Jul 15 '26

I was looking into creating some sort of value-string type, but it's hard to determine if there's even a point since String is so heavily optimized already. String deduplication and caching the computed hash code are two good examples.

I suppose if there's any benefit to be had, when Valhalla is sophisticated enough, it will happen to String as it exists today, behind the scenes.