[Enhancement] Add Nullable annotations to nullable Message getters and fix kotlin-stdlib transitive leak

[obabichevjb]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Two independent issues:

1. Seven getters in Message.java return null at runtime but have no nullability metadata. This causes silent NPEs and prevents both Java IDEs and Kotlin from warning the caller.
2. A pure-Java project depending on rocketmq-client transitively receives kotlin-stdlib on its classpath via an uncovered okhttp dependency edge.

Motivation

Nullable getters: getTags(), getKeys(), getProperty(), getUserProperty(), getBuyerId(), getProperties(), and getTransactionId() all return null under normal conditions (e.g., getKeys() is null unless explicitly set; getTags() is null when the producer omitted the tag). A Java user reported the same getTags() null problem in #1453 in 2019 — the issue was closed with no annotation or fix.

kotlin-stdlib leak: Upstream already wrote kotlin-stdlib exclusions for the okio-jvm dependency edge. However, an independent path — opentelemetry-exporter-otlp → opentelemetry-exporter-sender-okhttp → okhttp — still brings kotlin-stdlib in. This ships Kotlin's runtime to every user, including pure-Java projects that have no Kotlin dependency.

Describe the Solution You'd Like

Nullable getters: Add @Nullable (javax.annotation.Nullable, already available via org.apache.tomcat:annotations-api) to the seven affected getters in Message.java. This is a pure-metadata change with zero behavioral impact.

kotlin-stdlib leak: Extend the exclusion to cover com.squareup.okhttp3:okhttp and com.squareup.okhttp3:okhttp:3.x (which transitively pulls kotlin-stdlib-jdk8 and kotlin-stdlib-jdk7) in the opentelemetry-exporter-otlp dependency declaration. This enforces the constraint upstream already wrote for okio-jvm — no new policy decision required.

Describe Alternatives You've Considered

Additional Context

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: module/client (Message.java), Maven dependency declarations
Compatibility: No breaking changes — pure metadata addition and dependency exclusion

This is a well-specified enhancement with two independent parts:

1. @nullable annotations — Adding @Nullable to the seven getters (getTags(), getKeys(), getProperty(), getUserProperty(), getBuyerId(), getProperties(), getTransactionId()) is a low-risk, high-value change. It improves IDE warnings, prevents silent NPEs, and enables proper Kotlin interoperability. The reference to the unresolved Tags null while the CommitLog#handleHA() #1453 (2019) shows this is a long-standing pain point.

2. kotlin-stdlib transitive leak — Extending the existing okio-jvm exclusion to cover the opentelemetry-exporter-sender-okhttp → okhttp path is consistent with the project's existing dependency hygiene policy. Pure-Java consumers should not receive kotlin-stdlib transitively.

Both changes are straightforward and can be addressed in a single PR or split into two focused PRs.

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Feasibility: Feasible
Scope: API ergonomics — adding nullability annotations
Compatibility: Backward compatible (compile-time only)

Adding Nullable/NonNull annotations improves IDE support and Kotlin interop. This is a low-risk improvement that helps developers catch null-related issues at compile time.

---

Automated evaluation by github-manager