Bumping this for visibility — happy to address any concerns about the API shape, parameter naming, or compatibility approach.
If anyone has time to take a look at the PR (https://github.com/apache/pulsar/pull/25911), feedback would be much appreciated. Thanks, Pruthviraj On Mon, Jun 1, 2026 at 12:41 PM Pruthviraj Chandru <[email protected]> wrote: > > Hi all, > > I'd like to propose PIP-482, which adds a messagePosition parameter to the > Java admin client's Topics.peekMessages and peekMessagesAsync methods. > > The underlying REST endpoint: > > /admin/v3/persistent/{tenant}/{namespace}/{topic}/subscription/{subName}/position/{N} > > already accepts an arbitrary message position. The current Java admin client > hardcodes 1, so callers can only peek from the head of the backlog. > > The most common use case affected is paginated display in admin UIs. To show > the 91st–100th unacknowledged messages, callers currently have to fetch and > discard the first 90. > > This PIP surfaces the existing server capability at the Java client level. > > API surface (summary) > > The new primary abstract method: > > List<Message<byte[]>> peekMessages( > String topic, > String subName, > int messagePosition, > int numMessages, > boolean showServerMarker, > TransactionIsolationLevel transactionIsolationLevel) > throws PulsarAdminException; > > All pre-existing peekMessages overloads become default methods that delegate > to this primary method, giving the interface a single source of Javadoc. > > Compatibility > > This change is source- and behavior-compatible for all existing call sites. > The pre-existing 5-argument abstract peekMessages(..., numMessages, > showServerMarker, isolation) method becomes a default method, which is > binary-compatible according to the Java Language Specification. > > References > > Pull request: > https://github.com/apache/pulsar/pull/25911 > > PIP markdown: > https://github.com/Pruthvirajj240/pulsar/blob/pip-482-peek-messageposition/pip/pip-482.md > > Looking forward to feedback on the API shape, parameter naming, and > backward-compatibility approach. > > Thanks, > > Pruthviraj
