Question about Value Classes and inheritance

[David Alayachew]

Thank you both. So the answer boils down to, not enough realized value for
the effort involved. More specifically, it may foreclose on other things
while not really giving us much at all. Makes sense, and that's fair.




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


On Tue, Sep 23, 2025, 9:33 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Ok, but there doesn't seem to be any way to say "only value classes can
> extend me!”
>
>
> At some level, this is a matter of taste and return-on-complexity.
> Obviously this is not _needed_, but some programmers are clearly comforted
> by the ability to capture this intent.  Of course, adding such restriction
> adds complexity at every layer; it needs a syntactic expression, it needs a
> clasfile representation, it needs static type checking, it needs dynamic
> enforcement, it needs reflection, etc.  So the first question is: does the
> incremental expressiveness justify the incremental complexity?
>
> But more importantly, as Remi points out, seemingly harmless “intent
> capturing” things at the source level can turn into unexpected difficulties
> for longer term issues such as migration compatibility.  We saw a similar
> example of this in Java 8, where people asked “why can’t I make a default
> method final”, but then when you show them the impossible problems this
> creates for subclasses, they change the subject.  Foreclosing on
> possibilities like this, that are often “over the maintenance horizon”, are
> often “shallowly sensible” but make the ecosystem brittle.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/1d85feef/attachment-0001.htm>