jnigen: give byte-backed Kotlin values content equality

[milyin]

Reported on ZettaScaleLabs/zenoh-flat-jni#16: generated values with equal contents compare unequal.

Timestamp(1uL, byteArrayOf(1, 2, 3)) == Timestamp(1uL, byteArrayOf(1, 2, 3))  // false
EntityGlobalId(ZenohId(byteArrayOf(1)), 7) == EntityGlobalId(ZenohId(byteArrayOf(1)), 7)  // false

A generated class mirrors a Rust type deriving PartialEq/Eq, so this is the generator contradicting the type it mirrors — not a binding bug.

What Kotlin actually does

Measured on Kotlin 1.9.0 before writing any code:

	==	hashCode equal
@JvmInline value class V(val b: ByteArray)	❌ false	✅ true
data class D(val n: ULong, val id: ByteArray)	❌ false	✅ true
data class holding the value class	❌ false	✅ true
plain class + explicit content ops	✅ true	✅ true

Kotlin is inconsistent, not uniformly identity-based: a data class's generated hashCode/toString do special-case arrays (contentHashCode/contentToString) while its equals does not. That is why the report saw eq=false hashEq=true — a broken value finds the right HashMap bucket and is then rejected. == is the observable defect; a hashCode check alone would not have found it. (hashSetOf(t1, t2).size == 2 confirms the practical damage.)

Why value blobs lose @JvmInline

Kotlin 1.9 rejects the members outright:

e: Member with the name 'equals' is reserved for future releases
e: The feature "custom equals in value classes" is experimental and should be enabled explicitly

So an inline value class cannot be given value equality at this language level, and the experimental typed-equals replacement would force an opt-in flag on every consumer of a shared tier. Value blobs are therefore emitted as a plain data class.

Cost: one small allocation per crossing at the wrapper tier. The JNI ABI is untouched — externs already declare ByteArray (external fun zenohIdToString(z: ByteArray, …)) and the wrapper passes .bytes explicitly, so the erasure was never load-bearing. Value blobs are also documented as off-hot-path.

The change

equality::content_equality_members emits equals/hashCode/toString for any class with an array-backed constructor property and nothing for the rest, so existing classes keep the compiler's own generation and the diff stays confined. Three emitters feed it: data_class! (render.rs), value blobs and sealed_class! variant payloads (kotlin_emit.rs).

Coverage

Nothing exercised the broken shapes — covertest had the Stamp value blob but no data class with a ByteArray field, which is precisely why this reached a consumer. BlobValue adds both (a Vec<u8> field beside a scalar, plus a nested value blob) and the new section asserts content equality, hash equality, HashSet de-duplication, toString, and that each component participates (a comparison ignoring one would otherwise still pass).

Verified the section fails without the fix:

IllegalStateException: value blob must compare by content:
  Stamp(bytes=[7, 0, …]) vs Stamp(bytes=[7, 0, …])

PASS - 46 sections, 334 lib tests, fmt/clippy clean.

🤖 Generated with Claude Code

[milyin]

Changing the wrapper to a reference class also changes its JVM representation when it is stored in another generated object, but the whole-object input decoder still assumes value-class erasure. In this PR's generated JObject_to_BlobValue, native code does:

env.get_field(v, "stamp", "[B")

while the generated Kotlin field is now val stamp: Stamp, whose descriptor is Lio/prebindgen/covertest/model/Stamp;.

I reproduced this by marking the new BlobValue declaration .jobject_input(), adding blob_value_echo(BlobValue) -> BlobValue, and round-tripping the value. The JVM fails with:

java.lang.NoSuchFieldError: io.prebindgen.covertest.model.BlobValue.stamp [B

Please update the ProjectionKind::ValueBlob branch in emit/flat_input.rs to read the Stamp object and then its bytes (including nullable handling), and add this jobject-input round trip to the covertest. The old [B lookup was valid only while the field was inline-erased.

[milyin]

This classification fixes only a directly declared ByteArray, but supported container shapes can still contain arrays and retain identity equality. For example, adding chunks: Vec<Vec<u8>> to the new BlobValue generates:

val chunks: List<ByteArray>
// ...
chunks == other.chunks

Two independently returned values with equal chunks then fail the PR's own equality assertion, and toString() renders the nested element as [B@...:

BlobValue(... chunks=[[B@3830f1c0], ...) !=
BlobValue(... chunks=[[B@39ed3c8d], ...)

Vec<Vec<u8>> resolves and the binding compiles, so this is not an unsupported source shape. Please make the content operations recursive through array-bearing containers (and cover this case), or explicitly reject such properties instead of silently emitting identity semantics.

[milyin]

Both confirmed and fixed in a8025dc. Both were consequences of the value blob becoming a real class that I failed to trace.

1. Whole-object input read the wrong descriptor

Exactly as you diagnosed: [B was correct only while the wrapper was @JvmInline-erased. struct_input_body's ProjectionKind::ValueBlob branch now reads the wrapper object and then its bytes:

env.get_field(v, "stamp", "Lio/prebindgen/covertest/model/Stamp;")   // wrapper
env.get_field(&__stamp_jobj, "bytes", "[B")                          // then bytes

A null wrapper still yields a null [B, so the field's own converter carves None exactly as before.

I also fixed read_kotlin_property (sealed-class payloads), which made the identical assumption by falling through to jni_field_access — that maps a JByteArray wire to [B. You didn't report it, but the two paths differ only in which JVM object they read the field off, so a value-blob payload on a sum would have failed the same way.

2. Content operators stopped at the property

You're right that this isn't an unsupported source shape. array_bearing / eq_expr / hash_expr / str_expr now recurse through containers:

chunks.size == other.chunks.size && chunks.indices.all { __i ->
    val __x = chunks[__i]; val __y = other.chunks[__i]; __x.contentEquals(__y) }
// hash
result = 31 * result + (chunks.fold(1) { __acc, __e -> 31 * __acc + __e.contentHashCode() })
// toString -> chunks=[[9], [8, 7]]

A container of classes is deliberately untouched — those already compare by value, so only an array at the bottom makes a property array-bearing. The container fold uses the same 31 multiplier as Arrays.hashCode, so a List and the array it came from agree.

Coverage

BlobValue gains chunks: Vec<Vec<u8>> and is declared .jobject_input() with a blob_value_echo round trip — your two reproductions, kept.

I verified each assertion catches its own defect rather than assuming:

reverted	observed
the container recursion	chunks=[[B@182decdb, …] vs [[B@4361bd48, …] — assertion fails
the wrapper descriptor	NoSuchFieldError: io.prebindgen.covertest.model.BlobValue.stamp [B

PASS - 46 sections, 334 lib tests, fmt/clippy clean.

[milyin]

Superseded by #209, which removes the value blob entirely rather than making it comparable.

The equality work here is carried forward in #209 (commits preserved) — it is still needed for Timestamp.id and ZenohId.bytes, and is widened there to every Kotlin primitive array rather than just ByteArray.

Why supersede instead of merge: the review of this PR surfaced two more defects in the blob's raw-memory representation (a wrong JVM field descriptor once the wrapper stopped being @JvmInline-erased, and identity comparison through containers), and planning the fix surfaced a third — the input path read_unaligned-ed caller-supplied bytes after a length check only, which is UB for any type whose bit patterns aren't all valid. Copy doesn't imply that and no trait asserts it.

Teaching the resolver about [T; N] removes the blob's only reason to exist, so #209 deletes the representation rather than continuing to patch it.