Protobuf fields should not be checked for nullness about sdk-platform-java HOT 4 CLOSED

@Neenu1995 @chingor13 FYI

from sdk-platform-java.

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.

from sdk-platform-java.

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.

from sdk-platform-java.

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.

from sdk-platform-java.