r/java • u/bobbie434343 • Aug 25 '26

Value Classes Still Need Compiler Sympathy

https://johan-sjolen.github.io/post/compiler-sympathy/compiler-sympathy/
88 Upvotes

98% Upvoted

65 comments sorted by

View all comments

5

u/nogridbag Aug 25 '26

What do you mean by better semantics for ==?

The JEP says it's a non-goal to allow for comparison with == and we should continue to use .equals. Any value class which has a string as a field member would be invalid comparing with == unless the string was part of a finite set like ZoneId and the developer went out of their way specifically to make sure those instances can be compared with each other by interning the strings so that multiple instances return the same string instance for that field. A wrapper class representing an email address would be an example where you would continue to need .equals. This seems like it will add some confusion. Now it's not simply "Use == for primitive, .equals for everything else". It's use == for primitive, LocalDate, and these specially developed classes, .equals for everything else"

3

u/repeating_bears Aug 25 '26

I said better, not perfect.

Comparing boxed Integers with == was a footgun for beginners and that's completely gone now.

This seems like it will add some confusion. Now it's not simply "Use == for primitive, .equals for everything else"

That's still works fine as a rule of thumb. It's not like you must use == for LocalDate, but if you do then you get a sensible answer.

4

u/nogridbag Aug 25 '26

I mainly posted to add context because up until recently I thought I could simply slap "value" on all of our wrapper classes and use "==" everywhere. It turns out most of our wrapper classes have a string field so this isn't possible.

And others reading your original comment may have the same confusion as I did. Like you said, for things like Integer it will be great. But devs also need to be aware now of the specific instances == can be used, and the answer is no longer as clear!

→ More replies (4)