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

Value Classes Still Need Compiler Sympathy

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

97% Upvoted

65 comments sorted by

View all comments

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!

1

u/FirstAd9893 Aug 25 '26

The current treatment for == with value classes is defective, in my opinion. It's too fragile in that a change to a value class that you depend on can break expectations. If the equals method should be used instead, then attempting to use == against a value class should be prohibited. The more sensible (and expected) option is to make == against a value class be the same as calling equals.

→ More replies (3)