On Thu, 26 Mar 2026 02:02:54 GMT, Yasumasa Suenaga <[email protected]> wrote:
> In #30392, we found out some impl classes in FFM are marked as value based
> class, but they do not have `@ValueBased`.
> I grep'ed JDK sources with 'ValueBased.html' which we expect that the word in
> Javadoc on value based class, and I tracked it to final implementation class.
> `final` classes in following list should have `@ValueBased`.
>
>
>
> java.base/share/classes/java/lang/foreign/FunctionDescriptor.java
> public sealed interface FunctionDescriptor permits FunctionDescriptorImpl
> public final class FunctionDescriptorImpl implements FunctionDescriptor
>
> java.base/share/classes/java/lang/foreign/MemoryLayout.java
> public sealed interface MemoryLayout permits SequenceLayout, GroupLayout,
> PaddingLayout, ValueLayout
> public sealed interface SequenceLayout extends MemoryLayout permits
> SequenceLayoutImpl
> public final class SequenceLayoutImpl extends
> AbstractLayout<SequenceLayoutImpl> implements SequenceLayout
> public sealed interface GroupLayout extends MemoryLayout permits
> StructLayout, UnionLayout
> public sealed interface StructLayout extends GroupLayout permits
> StructLayoutImpl
> public final class StructLayoutImpl extends
> AbstractGroupLayout<StructLayoutImpl> implements StructLayout
> public sealed interface UnionLayout extends GroupLayout permits
> UnionLayoutImpl
> public final class UnionLayoutImpl extends
> AbstractGroupLayout<UnionLayoutImpl> implements UnionLayout
> public sealed interface PaddingLayout extends MemoryLayout permits
> PaddingLayoutImpl
> public final class PaddingLayoutImpl extends
> AbstractLayout<PaddingLayoutImpl> implements PaddingLayout
> public sealed interface ValueLayout extends MemoryLayout permits
> ValueLayout.OfBoolean, ValueLayout.OfByte, ValueLayout.OfChar,
> ValueLayout.OfShort, ValueLayout.OfInt, ValueLayout.OfFloat,
> ValueLayout.OfLong, ValueLayout.OfDouble, AddressLayout
> sealed interface OfBoolean extends ValueLayout permits
> ValueLayouts.OfBooleanImpl
> public static final class OfBooleanImpl extends
> AbstractValueLayout<OfBooleanImpl> implements ValueLayout.OfBoolean
> sealed interface OfByte extends ValueLayout permits
> ValueLayouts.OfByteImpl
> public static final class OfByteImpl extends
> AbstractValueLayout<OfByteImpl> implements ValueLayout.OfByte
> sealed interface OfChar extends ValueLayout permits
> ValueLayouts.OfCharImpl
> public static final class OfCharImpl extends
> AbstractValueLayout<OfCharImpl> implements ValueLayout.OfChar
> sealed interface OfSho...
I've double checked the API javadoc -- and both MemoryLayout/MemorySegment and
Linker have disclaimer such as:
* @implSpec
* Implementations of this interface are immutable, thread-safe and
* <a
href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>.
```
Which is good, as it supports the changes in this PR. Now, my personal
preference would be to focus on:
* `MemoryLayout`
* `MemorySegment`
As I don't think the value based-ness of Linker is particularly useful -- we
should probably take a second look there and see if we really want to keep that
disclaimer there.
As for `MemorySegment` I think we should be ok. `==` on segments almost always
doesn't do what people expect. For instance, `segment == MemorySegment.NULL`
doesn't always work reliably because, even though FFM tries to dedup nulls,
`reinterpret` can get in the way.
So once segments will become value classes, their value-based `==` will be very
picky, and look at base, offset and arena/scope. Whereas `equals` will continue
to work as it does today, returning `true` only when two segments really point
to the same underlying memory address. So I think that's all good. But let's
keep `Linker` (and its subclasses) out of it, for now.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/30443#issuecomment-4138804128
