[ISSUE #10978] Add Nullable annotations to nullable Message getters and stop kotlin-stdlib transitive leak

[jokerzsd]

What is the purpose of the change

Two independent fixes from issue #10978:

1. Nullable getters: annotate the seven Message getters that return null under normal conditions — getTags(), getKeys(), getProperty(), getUserProperty(), getBuyerId(), getProperties(), getTransactionId() — with javax.annotation.Nullable. Pure metadata, no behavioral change; lets Java IDEs and Kotlin callers detect the nullability.

2. kotlin-stdlib transitive leak: exclude com.squareup.okhttp3:okhttp from the opentelemetry-exporter-otlp dependency in common/pom.xml. The unused HTTP sender (RocketMQ uses the gRPC exporter) pulled kotlin-stdlib into every pure-Java consumer. This mirrors the kotlin exclusions already applied to the okio-jvm edge in the root pom.

Brief changelog

• common/src/main/java/org/apache/rocketmq/common/message/Message.java: add @Nullable to seven getters.
• common/pom.xml: add okhttp exclusion to opentelemetry-exporter-otlp.

Verifying this change

• mvn -f common/pom.xml compile — BUILD SUCCESS (checkstyle + spotbugs pass).
• mvn -f common/pom.xml dependency:tree -Dincludes=org.jetbrains.kotlin — no kotlin artifacts remain in the tree.

Closes #10978

[RockteMQ-AI]

Summary

Two clean, well-scoped fixes for #10978 — @Nullable annotations on seven Message getters and an okhttp transitive exclusion to stop kotlin-stdlib leaking into pure-Java consumers.

Findings

• [Info] common/src/main/java/.../Message.java — The @Nullable annotations correctly document the existing null-returning contract of getTags(), getKeys(), getProperty(), getUserProperty(), getBuyerId(), getProperties(), and getTransactionId(). Good improvement for Kotlin interop and static analysis.
• [Info] common/pom.xml — The okhttp exclusion on opentelemetry-exporter-otlp is correct since RocketMQ uses the gRPC exporter. Verified jakarta.annotation-api:1.3.5 in the parent POM provides javax.annotation.Nullable, so the import resolves without adding a new dependency.
• [Info] No behavioral change — purely metadata additions and dependency cleanup. No new tests needed.

Verdict

LGTM. Clean, minimal, and well-documented.

[RockteMQ-AI]

Summary

This PR makes two independent improvements from issue #10978: adding @Nullable annotations to Message getters and excluding an unused transitive dependency. Both changes are clean, well-scoped, and address real pain points.

Findings

• [Info] Message.java:102 — @Nullable annotations correctly applied, improves Kotlin interop
• [Info] common/pom.xml:70 — okhttp exclusion prevents kotlin-stdlib leak, mirrors existing pattern

Strengths

✅ Annotations are pure metadata, no behavioral risk
✅ Dependency exclusion is surgical and well-justified
✅ PR description clearly explains both changes and their rationale
✅ Verification steps included (compile + dependency tree check)

Verification

The PR description shows:

• mvn compile passes with checkstyle + spotbugs
• dependency:tree confirms no kotlin artifacts remain

This is a low-risk, high-value change for Kotlin consumers and dependency hygiene.

[RockteMQ-AI]

[Info] The @Nullable annotations are correctly applied to all seven getters that can legitimately return null. This improves IDE support and Kotlin interop without changing runtime behavior.

One minor note: javax.annotation.Nullable is from JSR-305 (legacy). Modern Java projects sometimes prefer org.jetbrains.annotations.Nullable or @org.checkerframework.checker.nullness.qual.Nullable, but javax.annotation.Nullable is widely recognized and works well with Kotlin's null-safety. No action needed.

[RockteMQ-AI]

[Info] The okhttp exclusion is well-targeted. Since RocketMQ uses the gRPC exporter (opentelemetry-exporter-otlp with gRPC transport), the HTTP sender (okhttp) is unused and was pulling kotlin-stdlib transitively into pure-Java consumers.

This mirrors the existing okio-jvm exclusion pattern in the root pom and keeps the dependency tree clean for Java-only deployments.