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 <[email protected]> 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 <[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]> wrote: > > > > ------------------------------ > > *From: *"David Alayachew" <[email protected]> > *To: *"valhalla-dev" <[email protected]> > *Sent: *Tuesday, September 23, 2025 2:19:40 PM > *Subject: *Question about Value Classes and inheritance > > Hello @valhalla-dev <[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 > >
