Value-based classes in jdk.incubator.foreign

[Maurizio Cimadamore]

That's all good - thanks for the headsup.

I think, as I commented elsewhere, some of the issues with the current 
hierarchy in the foreign memory access API stem from transient choices 
(such as that of using a stateful intermediate class for layouts). I 
think that, moving forward, we can easily adhere to the final 
value-based specification.

Maurizio

On 24/11/2020 19:38, Dan Smith wrote:
> 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.