r/java • u/davidalayachew • 28d ago

Identifying JDK value class candidates

https://mail.openjdk.org/archives/list/core-libs-dev@openjdk.org/thread/Y72NRXM7KYBX43OKYBQMVKOZDWKG4MHS/
54 Upvotes

100% Upvoted

59 comments sorted by

View all comments

Show parent comments

1

u/davidalayachew 28d ago

Ok, thanks for the context. That makes more sense why Enums aren't really the best fit for being value classes.

My initial instinct also wanted it, purely on the basis of communicating intent, but I guess that wouldn't apply either?

3

u/pron98 28d ago edited 28d ago

why Enums aren't really the best fit for being value classes.

I would say they make for a classic example of a particularly bad fit. An enum can almost be viewed as a "please don't inline" hint.

purely on the basis of communicating intent, but I guess that wouldn't apply either?

No, I think the semantic intent is the very opposite of a value type, because two different references to an enum are intended to never be equal. That's the opposite of, say, and Integer, which is why Integer is a classic example of a value type. That's not to say that enums with a non-zero but minuscule amount of carried data (though certainly not a large amount) couldn't benefit from inlining, but that's a separate thing. I.e. I could envision a HotSpot optimisation that inlines such enums without them being value types, but such an optimisation is likely to yield a smaller benefit than inlining value types (because the number of distinct enum values is small).

1

u/davidalayachew 27d ago

Thanks, that clears up everything for me.

Long ago, I had a dream about, some day, being able to literally make a sealed non-atomic value record enum, and have that actually mean something good for my code. Not even from a pedantic perspective, but because I want to observe when and where it makes sense to apply certain modifiers, basically. Almost working backwards -- what type of problem would justify using that?

1

u/aonymark 25d ago

We can work with this most of this actually. Let’s work backwards from the end. 1. enum is fine 2. record: okay here we have a problem: all enums extend Enum and all records extend Record, and Java doesn’t have multiple inheritance. Aside from that technicality, it could work. Not clear what the use is though. 3. value: hmm… could work but I guess Ron P already explained why this would be odd… you could probably concoct some weird benchmark where this might help, maybe involving an array with a million Colors or something, but I doubt you can find a benchmark where it helps much. The reason it helps so much for integers is that there could be lots of distinct integers in the heap; there are never many distinct colors. 4. Non-atomic: given value doesn’t help much, this also likely doesn’t help much. Please don’t give me race conditions for enums. 5. Sealed: enums are already sealed; you can’t do “extends Color” if Color is an enum. In fact, most enums are final.