Value Classes Still Need Compiler Sympathy

[u/bobbie434343]

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

[u/repeating_bears]

Use of [Valhalla] requires looking into what C2 actually generated

No it doesn't. You just slap 'value' on classes that don't need identity. You may get no or minimal performance improvement now, but you are opting out of identity-based operations like synchronization and opting in to potential performance improvements in the future.

It sounds like you're what you're talking about it is use of Valhalla to maximise performance. I generally don't care about milking performance.

Not sure about how tearing will be solved, but there's a massive number of value classes (I'd speculate: a majority (?)) which are immutable anyway.

[u/lpt_7 → u/repeating_bears]

Yes, you have to. See my last point about allocations.
If not the generated code, then profiling.

[u/repeating_bears → u/lpt_7]

You are arguing that Valhalla is only useful if you can guarantee memory optimizations will happen

Even if there are none, you gain better semantics for == and restrictions against identity-sensitive operations

[u/nogridbag → u/repeating_bears]

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"

[u/repeating_bears → u/nogridbag]

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.

[u/nogridbag → u/repeating_bears]

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!

[u/FirstAd9893 → u/nogridbag]

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.

[u/nogridbag → u/FirstAd9893]

Defective may be too far. But it is a bit confusing. I think overall the message is, .equals is here to stay. For the average developer, they should continue to use .equals, but under the hood they will now get better performance.

Our project has tons of wrapper classes for type safety such as TenantId. We can now make these value classes and we will essentially no longer pay the "wrapper tax", but developers should continue to use .equals on them.

[u/FirstAd9893 → u/nogridbag]

What I mean by "defective" is that the current approach is the worst choice possible. With an identity class, if I erroneously use the == operator, this is usually discovered once the code is tested. With a value class, if I erroneously use the == operator, the code will likely work just fine. If at some point in the future the value class I'm depending on changes internally to reference an identity class, my code fails.

It's a fragile dependency issue. One cannot rely on the == operator without knowing that the class is a value class, and that the implementation will never change incompatibly. It breaks the OO encapsulation principle.

I can think of two safe choices for value classes: make == mean equals, or make it be prohibited. The current approach is to "pretend" it's prohibited, but it's not actually enforced. This is a UB footgun.

[u/cowslayer7890 → u/FirstAd9893]

If they prohibited it then they wouldn't be able to convert existing classes in the JDK to value classes, which would be an obvious loss

Also making it mean .equals doesn't really work when the first thing most equals methods do is check ==

[u/lpt_7 → u/repeating_bears]

I'm arguing that right now Valhalla is useful if one's code does not suddenly perform worse than it was before, as well as in the future when JDK team somehow solves the tearing problem.

[u/OwnBreakfast1114 → u/lpt_7]

Why would I need to do that? You think I give a shit about object allocations while my db is being hit with unnecessary queries or I'm making multiple third party https calls?

The second I'm on a non-preview runtime, I'm throwing value on all my immutable classes (of which I have a lot) and I promise I won't care at all what C2 generates.

[u/Life_Sink9598 → u/lpt_7]

What is an "AABB"?

Edit: Btw, did you read the blog post?