[robot-head]

When org.jspecify:jspecify is on the compile classpath, AutoValue 1.11.1 and later annotate the classes they generate with org.jspecify.annotations.Nullable. Recent Guava releases depend on jspecify, so a consumer's Maven graph usually includes it. The AutoValue targets here (//rls, //xds) don't depend on jspecify directly, so Bazel's Java strict-deps check rejects the generated sources.

grpc-java's own build passes on master because it pins AutoValue 1.11.0, which doesn't emit jspecify annotations. The failure shows up when a consumer's Maven graph resolves a newer AutoValue and puts jspecify on the AutoValue compile classpath.

This PR adds org.jspecify:jspecify:1.0.0 to IO_GRPC_GRPC_JAVA_ARTIFACTS in MODULE.bazel and repositories.bzl, and exports it from //:auto_value_annotations alongside auto-value-annotations, so every AutoValue user gets it.

Repro (Bazel 8.7.0, Bzlmod): a consumer module that depends on grpc-java through local_path_override and has a root maven.install with com.google.auto.value:auto-value:1.11.1, auto-value-annotations:1.11.1 and com.google.guava:guava:33.7.2-jre. On master, bazel build @grpc-java//rls fails:

AutoValue_RlsProtoData_RouteLookupRequestKey.java:33: error: [strict] Using type org.jspecify.annotations.Nullable from an indirect dependency (TOOL_INFO: "@maven//:org_jspecify_jspecify").

Testing with this change:

• The consumer above builds @grpc-java//rls and @grpc-java//xds.
• In this repo, bazel build --config=skip_android //rls //xds //:auto_value_annotations passes with Bzlmod, and //rls //:auto_value_annotations passes with --enable_bzlmod=false --enable_workspace=true.
• The GRPC_DEPS lists in MODULE.bazel and repositories.bzl still match, per the CI diff check.
• I didn't run the full bazel test //... or the Gradle build. Gradle isn't touched.

🤖 Generated with Claude Code

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: robot-head / name: robot-head (7db6a09)

[robot-head]

/easycla