Core: Reject negative ByteBuffer stream seeks

[charliec05]

Summary

• reject negative seek positions in both single- and multi-buffer input streams
• validate before resetting or advancing buffer state
• add shared regression coverage that runs against both implementations

Motivation

The two ByteBufferInputStream implementations handled negative positions inconsistently. MultiBufferInputStream silently accepted seek(-1) and reset to the beginning, while SingleBufferInputStream failed later inside ByteBuffer.position after it had already reset its state.

Both implementations now reject the invalid position before changing state, matching the behavior of Iceberg's other seekable streams.

Testing

• ./gradlew :iceberg-core:spotlessApply :iceberg-core:test
• ./gradlew :iceberg-core:spotlessCheck :iceberg-core:test --tests org.apache.iceberg.io.TestSingleBufferInputStream --tests org.apache.iceberg.io.TestMultiBufferInputStream

---

AI Disclosure

• Model: GPT-5 (Codex)
• Platform/Tool: OpenAI Codex
• Human Oversight: fully reviewed
• Prompt Summary: Used a detailed, repository-aware prompt to compare seek boundary behavior across implementations, reproduce inconsistent negative-position handling, require state preservation, review the minimal diff, and run both focused and complete Core tests.

[charliec05]

Hi @laskoviymishka, would you be willing to review this ByteBufferInputStream boundary fix? It makes both implementations reject negative seeks consistently while preserving stream state, includes shared regression coverage, and all 42 CI checks pass. Thanks!

[singhpk234]

when can this be negative ?

[charliec05]

newPosition is supplied by the caller through the public ByteBufferInputStream.wrap(...).seek(...) API. I have not identified a production call path that supplies a negative offset; I found this while testing invalid seek inputs.

On the base revision, after reading the first byte and then calling seek(-1), SingleBufferInputStream throws IllegalArgumentException but has already reset its position to 0, while MultiBufferInputStream accepts the call and also resets to 0. I reproduced both cases: the next read returns the first byte again. With this change, both reject the invalid offset while keeping position 1, and the next read returns the second byte.

The motivation is defensive validation before mutating stream state, consistent with the existing negative-seek guards in EagerInputStream, S3InputStream, and GCSInputStream. The shared regression test checks rejection and position preservation for both implementations.

[uros-b]

+1 here, please address any additional concerns from committers