RockteMQ-AI commented on issue #1350: URL: https://github.com/apache/rocketmq-clients/issues/1350#issuecomment-5438792120
**Issue Evaluation** Category: `type/enhancement` | Status: **Evaluated** **Feasibility:** Feasible — JSpecify `@NullMarked` annotations are `CLASS` retention, zero runtime cost, and the scope is well-defined (32 public types across 4 packages). **Scope:** `client-apis/java` — four `package-info.java` files covering `apis`, `apis.consumer`, `apis.message`, `apis.producer`. **Compatibility:** No breaking changes for Java consumers. Kotlin consumers gain compile-time nullability safety (platform types become non-null by default). JSpecify 1.0.0 as `provided` scope means no transitive dependency impact. **Assessment:** This is a valuable improvement for Kotlin interoperability, which is increasingly important as the Kotlin ecosystem grows in the JVM space. 1. **`@NullMarked` on four packages** — Correct approach. JSpecify package scope is not hierarchical, so four `package-info.java` files are needed. Marking ~99 return values and parameters as non-null by default matches the actual API contract (these methods do not return null). 2. **`SendReceipt.getRecallHandle()` exception** — Good catch. This is the only getter that breaks the `Optional<T>` convention. Documenting the empty-string sentinel with proper Javadoc (rather than an implementation-level comment) is the right fix. The suggestion to use `String.isEmpty()` rather than nullness checks is correct. 3. **JSpecify 1.0.0 as `provided`** — Correct dependency scope. `CLASS` retention means annotations are in compiled class files for downstream consumers without requiring them to add any dependency. 4. **Cross-language consideration** — This only affects the Java client-apis module. The Go/C++/C#/Rust clients have their own nullability mechanisms and are unaffected. The implementation is straightforward and low-risk. Looking forward to the PR. --- *Automated evaluation by github-manager* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
