feat(gapic-generator): Add Nullable annotation to generated classes

[nnicolee]

This PR updates the gapic-generator-java to add the JSpecify @nullable annotation to all generated class declarations. This is the second phase in onboarding the generated client libraries to compile-time safety validation, see design doc for more details: go/sdk:java-jspecify-null-annotations-gapic

Classes Annotated:

• Client Classes: AbstractServiceClientClassComposer
• Stub Classes: AbstractServiceStubClassComposer and ServiceStubClassComposer
• Resource Names: ResourceNameHelperClassComposer

Implementation Changes:

• Built the parameter variable expression in equals(Object o) as a reference initially, and attached the @nullable annotation during its method argument declaration (with isDecl = true). This prevents IllegalStateException crashes in the generator's strict AST validation engine.
• Leveraged a VaporReference type name-hacking trick to render generic type-use annotations (such as List<@nullable ResourceName>) without needing disruptive changes to the core AST reference rendering engine.

Verification/Testing:

• Please refer to this doc: https://docs.google.com/document/d/1h126pbTGqSwtJyl35E2_vQjM9gNtmWETYCM7PObcvmQ/edit?tab=t.0#heading=h.s4q06jxocx8b

[gemini-code-assist]

Code Review

This pull request introduces @Nullable annotations to various generated classes and generator code in the Java GAPIC generator. Specifically, it updates the composer classes to annotate settings fields, getter methods, non-required resource name helper arguments, parse methods, toStringList generic types, and equals method arguments, with corresponding updates to the golden files. A review comment highlights a fragile workaround in ResourceNameHelperClassComposer.java where the @Nullable annotation is hacked into the VaporReference name string, warning that this could lead to issues with type comparisons, fully qualified names, AST manipulation, and missing imports, and suggests extending the AST classes to properly support type-use annotations.

[sonarqubecloud]

Quality Gate passed for 'gapic-generator-java-root'

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
89.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed for 'gapic-generator-java-root'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[lqiu96]

Can you double check this one? Do we need to add an annotation here for paging?

[nnicolee]

Hi! Yes, we need to add an annotation here because two places call this function (createCollection and createEmptyCollection (on line 1590-1) which calls the function with null in the first parameter (which is pages). Verified this annotation with Nullaway!

[lqiu96]

qq, I don't think we should change this. Perhaps better to mark the param as nullable?

[diegomarquezp]

+1 the new logic may affect this, which is a good way to catch additional cases where @Nullable is needed.

[diegomarquezp]

Discussed with @nnicolee, looks like setName is a proto class, which we don't have control over, and is being marked by NullAway with:

[ERROR] /usr/local/google/home/nicolejlee/google-cloud-java/java-showcase/gapic-showcase/src/main/java/com/google/showcase/v1beta1/MessagingClient.java:[1822,64] error: [NullAway] passing @Nullable parameter 'parent == null ? null : parent.toString()' where @NonNull is required

If it was possible to configure ErrorProne to ignore proto classes in these cases that would be great. That could be a good first step.
On the other hand, looks like Proto classes actually can take nulls (since the code's been like this), which can be worked around by adding a warning suppression as Nicole suggested.

[lqiu96]

same here, should be type-use annotation here.