Protobuf fields should not be checked for nullness

[dpcollins-google]

Java codegen for list methods should not generate null checks like this one for proto fields https://github.com/googleapis/java-pubsublite/blob/da98b0f8212d33ace2e3f9d034f7a923ef05c43a/google-cloud-pubsublite/src/main/java/com/google/cloud/pubsublite/v1/stub/AdminServiceStubSettings.java#L187

This is a hard blocker for pulling these libraries into the google codebase which has a compiler error for null checks on protobuf fields. Per https://developers.google.com/protocol-buffers/docs/reference/java-generated, java protobuf fields will never return null.

Environment details

• Programming language: Java
• OS: All
• Language runtime version: All
• Package version: All

Steps to reproduce

1. Write a java client library with a list request
2. Codegen adds redundant check

[miraleung]

@Neenu1995 @chingor13 FYI

[miraleung]

This null check originates from the monolith generator. On investigating, this was introduced for a very specific reason, context below.

• Original bug
• Relevant discussion in the bugfix, where the necessity of this check was initially debated.

I'll add a comment to the code to indicate this check is WAI. Removing this check would introduce a bug in client libraries who do return null instead of an empty list, so closing this issue.

[dpcollins-google]

Going to reopen. The bug and discussion refer to com.google.api.services.compute.model.Image, note the model in the name. This refers to the old HTTP generated libraries, not protobuf libraries, indeed you can see it overrides GenericJson not AbstractMessage. Are there still generated clients which use the old HTTP bindings, not the protobuf ones? If so, this check may indeed be necessary for those clients. But if no such libraries are generated (or generatable) with the version at head, this check may safely be removed.

[miraleung]

The microgenerator supports a superset of the monolith's features, and it's unclear if there are clients who do the same thing as the use case mentioned in the original bug. I would prefer not to introduce a potential breakage to one of the ~200 client libraries we support, but if you can confirm that none of them return null instead of an empty list (and paste that here), we can revisit making this change.

In the meantime, the import issue can be addressed by post-processing the generated library, either manually (as is currently done) or with a script.