Hi David, In the value objects world, we can think of identity as an extra field on an object that is distinct for every object creation. Due to the uniqueness of this field, we can have shortcuts for hashCode/== that is still compliant but much simpler. The proposal to block identity subtypes for abstract value types would be equivalent to blocking subtypes from declaring particular types of fields or implementing particular interfaces (all interfaces are now abstract value, too).
If you want to ensure safety for abstract value classes, sealed modifier is your friend - they ensure an AVC only has particular subtypes and might be optimized to union types by JVM implementations. Otherwise, if a field allows arbitrary value subtypes, they still must be stored as references just like for identity objects. In this case, allowing identity subtypes has little performance impact. Regarding the perceived "lack of safety" for identity classes, I would argue it is not associated with identity, but with the mutable fields enabled by identity. In fact, in the investigations of heap-flattened value objects and var handles, we find that referring to large value objects as reference pointers is the best way to ensure volatility - because pointers are small enough to be updated atomically. Feel free to ask further if you have more overview questions. Regards, Chen ________________________________ From: valhalla-dev <[email protected]> on behalf of David Alayachew <[email protected]> Sent: Tuesday, September 23, 2025 8:50 AM To: Remi Forax <[email protected]> Cc: valhalla-dev <[email protected]> Subject: Re: Question about Value Classes and inheritance To answer your question specifically Rémi, I figured this would be useful to prevent things like misuse. For example, the JEP shows how BigInteger can't be a value class due to its internal use of mutability. Well, something like enforcing value classes might have prevented that. Or maybe not, I am ignorant about that example specifically. But hopefully you see my point? It feels like there a lot of validation opportunities being left on the table. Value classes aren't just faster, they are safer. So, being able to assert that safety for all child classes seems nice. Or maybe I am wrong, and Value classes aren't inherently safer. Finality feels safe to me, and finality by default feels safer. Idk. Truthfully, I'm operating more on feelings here than genuine experience. I'll have something more concrete (or see where I'm wrong) to say once the new EA comes out. On Tue, Sep 23, 2025, 8:31 AM Remi Forax <[email protected]<mailto:[email protected]>> wrote: ________________________________ From: "David Alayachew" <[email protected]<mailto:[email protected]>> To: "valhalla-dev" <[email protected]<mailto:[email protected]>> Sent: Tuesday, September 23, 2025 2:19:40 PM Subject: Question about Value Classes and inheritance Hello @valhalla-dev<mailto:[email protected]>, I read through JEP 401, and the subsection about subtyping surprised me. It appears that Abstract Value Classes can permit both Value child classes and Identity child classes. The example of BigInteger helps explain why. Ok, but there doesn't seem to be any way to say "only value classes can extend me!" Why is that? And to be clear, I am not bothered by Abstract Value Classes permitting Identity children, that's fine. I'm glad this is fine by you because it's important for backward compatibility, it means that you can declare an existing abstract class has "value enable", without requiring sub-classes to be changed. I'm moreso confused by lack of ability to say "only value children". Declaring a class has a value class is really close to be an implementation detail (it mainly depends on if your code abuse of == or not), so why do you want such ability ? Thank you for your time and consideration. David Alayachew regards, Rémi
