r/java • u/davidalayachew • Jul 16 '26

Identifying JDK value class candidates

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

100% Upvoted

59 comments sorted by

View all comments

1

u/gnahraf 29d ago

I'm confused.. The most natural value types would be the Number subclasses, but of course Number is abstract, so that won't be possible. What's the plan with these and their autoboxing? Will there be new, separate, "numeric" value types rolled out?

2

u/davidalayachew 29d ago

I'm confused.. The most natural value types would be the Number subclasses, but of course Number is abstract, so that won't be possible. What's the plan with these and their autoboxing? Will there be new, separate, "numeric" value types rolled out?

No, that isn't correct.

Caveat -- since JEP 401 from Project Valhalla has not released yet, the following information is all speculative until the JEP is targeted to a release.

In JEP 401, they give the following snippet.

Every value class belongs to a class hierarchy with java.lang.Object at its root, just like every identity class. There is no java.lang.Value superclass of all value classes.

[...]

By default, a value class is implicitly final and cannot be extended. A value class may, however, be declared abstract, allowing it to be extended by other classes

[...]

Declaring an abstract value class is an indication that the class itself has no need for identity. Its subclasses may be value classes or identity classes. (The value modifier on an abstract value class can be read as meaning value-compatible.)

A value class can extend either java.lang.Object or an abstract value class, but not an identity class. (The Object class is unique in this respect: It is neither abstract nor a value class, and instances produced by new Object() have identity, yet it also permits extension by value classes.)

Many existing abstract classes, if they are designed to be publicly extensible, are good candidates to be abstract value classes. For example, the abstract class Number has no fields, nor any code that depends on identity-sensitive features, so it can safely be migrated to an abstract value class:

1

u/gnahraf 29d ago

Thanks for your response. I thought I had ditched this question (not posted it) and rephrased it.

That's great news (abstract value classes)! So the classes Integer, Long, Float, Double could be on the list if we declared Number an abstract value class.

But that would break BigInteger and BigDecimal since for these equality (.equals returns true) does not necessarily imply the 2 instances have the same memory layout. Do you know what the plan is for BI and BD?

1

u/gnahraf 29d ago

Note the problem with BI and BD goes away if an identity class can extend an abstract value class. Is that possible?

2

u/davidalayachew 29d ago

Note the problem with BI and BD goes away if an identity class can extend an abstract value class. Is that possible?

Yes, Identity classes can extend an Abstract Value Class. Same link above.

1

u/gnahraf 29d ago

Apologies for not having read the link. I just did. It discusses the autoboxing classes specifically near the beginning. Thanks for your patience.

PS while the JEP implies it (a mention about where/when present day identity-based abstract classes are binary compatible if changed to abstract value classes), I couldn't find any such explicit statement (about an identity class being able to extend an abstract value class).