[Fix][Engine] Fix JDK 8 NoSuchMethodError in StainTracePayload#append

[davidzollo]

Purpose

Fix a JDK 8 runtime incompatibility in StainTracePayload#append.

Problem

In JDK 9+, ByteBuffer added a covariant override of Buffer.position(int) that returns ByteBuffer instead of Buffer.
When the project is compiled on JDK 9+ (which emits bytecode referencing ByteBuffer.position(I)LByteBuffer;) and then run on JDK 8, the JVM cannot resolve that method descriptor and throws:

java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;

The affected line is in append():

// before – compiled reference to ByteBuffer.position(I)LByteBuffer; → NoSuchMethodError on JDK 8
buffer.position(payload.length);

Fix

Cast to the Buffer superclass so the call always resolves to Buffer.position(I)LBuffer;, which exists on every JDK version:

((Buffer) buffer).position(payload.length);

This is the standard idiom used throughout the JDK and many libraries to keep ByteBuffer code compatible with JDK 8.

Checklist

• Code compiles and existing unit tests (StainTracePayloadTest) pass
• No behaviour change – only the method-resolution path in bytecode is affected

[nzw921rx]

+1 good job🚀

[DanielLeens]

Thanks for working on this. I reviewed the latest head from scratch and checked the exact binary-payload append path that runs when stain-trace sampling records another stage hop.

What this PR solves

• User pain: on JDK 8, StainTracePayload.append(...) can hit NoSuchMethodError because the compiled call targets the JDK 9+ covariant ByteBuffer.position(int) signature instead of the JDK 8 Buffer.position(int) signature.
• Fix approach: cast the wrapped buffer to Buffer before calling position(int), so the call binds to the JDK 8-compatible superclass method.
• One-line summary: this is a precise compatibility fix on the real payload-append hot path, and I did not find a new source-level blocker.

Runtime path I checked

sampled row trace path
  -> StainTracePayload.append(...) [81-101]
      -> validate payload
      -> expand byte array
      -> move write cursor to old payload length
      -> append stage code / task ID / timestamp
      -> update entry count

Review result

• StainTracePayload.java:90-100 is exactly the right place to fix this.
• The new cast at StainTracePayload.java:92-96 is minimal and targeted: it preserves the existing binary layout while avoiding the JDK 8 linkage problem.
• I did not see a reopened compatibility or payload-corruption risk from this change.

Tests / CI

• The code change is very small and the compatibility rationale is clear from the in-code comment.
• The current apache-side Build check is red, but the corresponding fork Actions run I inspected is still in progress and has not yet produced a clean final PR-specific failure diagnosis. So I am not treating that red badge as source evidence against this fix.

Conclusion: can merge after fixes

1. Blocking items

• No source-level blocker from my side on the latest head.
• Please make sure the branch ends up with one valid CI result before merge, because the current public Build badge is not a trustworthy final signal yet.

2. Suggested non-blocking follow-up

• None from my side on this code path.

From the code-review side, the JDK 8 compatibility fix itself looks good.