The committers listed above are authorized under a signed CLA.

• ✅ login: Kainsin / name: Kainsin (449cc94)

This is essentially the next step past #8687 . Still not totally off javax, but this should unblock projects that are affected by immutables/immutables#1529 👍

/gcbrun

The usage of javax.annotation.concurrent.ThreadSafe in grpc-java creates a specific risk for downstream projects, particularly those using the Immutables library on Java 11+, due to the following reasons:

1. Dependency on JSR-305
The ThreadSafe annotation is provided by the JSR-305 (com.google.code.findbugs:jsr305) library. In grpc-java, this is a transitive dependency that is exposed via the api
configuration.

2. High-Impact Subclassing
ThreadSafe is used on foundational gRPC classes that users are expected to extend:

• io.grpc.stub.AbstractStub: All generated gRPC stubs (Blocking, Async, Future) extend this class.
• io.grpc.Channel: Users often implement custom wrappers or interceptors that extend or delegate to this.
• io.grpc.ManagedChannel: A primary entry point for gRPC clients.
• io.grpc.Server: The core server class.

3. The "Immutables" Compilation Failure
Because these core classes are annotated with ThreadSafe, any downstream project that:

1. Uses Java 11 or later (where the javax.annotation package is no longer in the JDK).
2. Includes the Immutables annotation processor.
3. Excludes or fails to include the jsr305 jar (often done to avoid "split package" warnings in modular builds).

...will suffer a full project compilation failure. The Immutables processor will see the ThreadSafe annotation on the gRPC superclass, find it missing from the classpath, and crash.

4. Modular Java (JPMS) Conflicts
Even if the build doesn't fail, javax.annotation.concurrent.ThreadSafe causes headaches in modular Java environments. Since both JSR-305 and the standard javax.annotation-api (which contains @Generated) use the same javax.annotation package, they create a split package conflict. Many developers attempt to solve this by removing JSR-305, which then triggers the Immutables bug described above.

Summary of Problems

• Brittle Builds: Downstream projects may fail to compile if they try to "clean up" their dependency tree by removing what looks like an old FindBugs dependency (jsr305).
• Subclassing Obstacles: Simply implementing a gRPC client or server can break a build if the environment isn't perfectly configured to handle the legacy JSR-305 annotations.
• Tooling Incompatibility: Other static analysis tools or bytecode scanners (not just Immutables) may also warn or fail when encountering these "phantom" annotations from the superclass.