Value-based classes in jdk.incubator.foreign

Dan Smith daniel.smith at oracle.com
Tue Nov 24 19:38:32 UTC 2020


JEP 390 has done some work to reconcile the "value-based class" concept in JDK APIs with future primitive classes, as being designed in Valhalla.

One conclusion we reached is that it will not be helpful in the future to have distinct "value-based" and "primitive" properties for classes; the former should be superseded by the latter. A class should either be designated value-based, with the intent to eventually become a primitive class, or it should just avoid the "value-based" terminology and state directly whatever properties it wishes to advertise.

This has led to a revised definition of value-based class, which, among other things, asserts that the class is final and the superclass declares no instance fields. See here:

https://github.com/openjdk/valhalla/pull/222/files#diff-5b3f533129ebe96efc9d6d51a4bdf33b56dc8aa0586343c792621ebcbd4fb77e

This creates some problems for classes in jdk.incubator.foreign:

- Implementations of MemorySegment are supposed to be value-based, but are non-final and inherit fields.

- Subclasses of AbstractLayout claim to be value-based but inherit fields

For now, I've left the "this is a value-based class" comments in the javadoc, with some revisions in the boilerplate text.

https://github.com/openjdk/valhalla/pull/222/files#diff-11d74c4a0e74adb54334cb36c0e5e71fd9e2ab95269412cb3e040d8ce80d9726

If the intent is to eventually migrate these to be primitive classes, their hierarchies should be adjusted to satisfy the requirements. If not, we should remove the references to value-based classes.


More information about the panama-dev mailing list