Question about Value Classes and inheritance

[David Alayachew]

What an excellent explanation, ty vm Chen. No, this clarifies everything
for me, ty again.

On Tue, Sep 23, 2025, 12:13 PM Chen Liang <chen.l.liang at oracle.com> wrote:

> 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 <valhalla-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Tuesday, September 23, 2025 8:50 AM
> *To:* Remi Forax <forax at univ-mlv.fr>
> *Cc:* valhalla-dev <valhalla-dev at openjdk.java.net>
> *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 <forax at univ-mlv.fr> wrote:
>
>
>
> ------------------------------
>
> *From: *"David Alayachew" <davidalayachew at gmail.com>
> *To: *"valhalla-dev" <valhalla-dev at openjdk.java.net>
> *Sent: *Tuesday, September 23, 2025 2:19:40 PM
> *Subject: *Question about Value Classes and inheritance
>
> Hello @valhalla-dev <valhalla-dev at openjdk.java.net>,
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/2801406c/attachment-0001.htm>