protocolbuffers / protobuf

Protocol Buffers - Google's data interchange format
http://protobuf.dev
Other
65.2k stars 15.44k forks source link

Annotate nullability in generated code #5526

Open NN--- opened 5 years ago

NN--- commented 5 years ago

If it's about generated code change, what programming language? C#, Java

Describe the problem you are trying to solve. Generated code could be annotated with NotNull , CanBeNull attributes which improves developing experience and save from null value exceptions.

Describe the solution you'd like Generated code with annotations. They can be either added as external library or just included in the source See: https://blog.jetbrains.com/dotnet/2015/08/12/how-to-use-jetbrains-annotations-to-improve-resharper-inspections/ https://www.jetbrains.com/help/idea/annotating-source-code.html

Describe alternatives you've considered Alternative is to parse generated code and add annotations by myself. I don't really like this solution.

Additional context Add any other context or screenshots about the feature request here.

BSBandme commented 5 years ago

For java, internally in google protobuf isn't very easy to add new dependency like this (in google we can add guava to mark Nullable annotation if new dependency is allowed). So this improvement may not be seen in the near future.

perlun commented 5 years ago

I also agree that this would be useful. We are adding external annotations using annotations.xml at the moment but it feels like quite a kludge.

Supporting either com.google.code.findbugs:jsr305 (i.e. javax.annotations) or Guava annotations would be useful. Perhaps it could be an optional flag? I.e. you could run the protobuf compiler in "traditional" mode, imposing no extra dependency on the generated code whatsoever. This could be the perfect balance between "be conservative with adding new dependencies" and "add functionality generally useful for people".

If we'd go this route, I would even say that being able to configure what non-null annotation class to use would be perfect and a really great approach. (We are using javax.annotation.Nonnull ourselves, i.e. JSR305, which plays well with both IntellIJ IDEA and Spotbugs.)

(Note: I have no idea how hard this would be to implement in the Protobuf compiler.)

kolmant commented 3 years ago

I was going to post one issue about the same until I found this one. It would be super useful annotating arguments of setters with @NotNull, It throws NPE when null is passed anyway and make working with Protobuf in Kotlin way easier, since Kotlin offers a pretty good null safety when using pure Kotlin or just the Java standard library (and if you're not programming in a defensive way while using the generated code that could be a potential bug since Kotlin does not warn you about the exception).

kluever commented 3 years ago

@cpovirk re. nullness annotations

googleberg commented 2 years ago

protoc generated java code annotates non-null APIs with @com.google.protobuf.Internal.ProtoNonnullApi

cpovirk commented 2 years ago

Only inside Google, though :)

googleberg commented 1 year ago

My mistake. I thought these annotations were also in OSS. We should use the standard annotations rather than our custom ones.

perlun commented 1 year ago

@googleberg While you're at it, it would be great to get this looked into at some point: https://github.com/protocolbuffers/protobuf/issues/4351#issuecomment-1117284074. It's an incredibly annoying detail of the generated (Java) code where certain methods can in fact return null... :grimacing:

github-actions[bot] commented 4 months ago

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

slovdahl commented 4 months ago

Still very valid issue.

git-torrent commented 4 months ago

With edition 2023 and explicit presence, can be (e.g.) C# generator tweaked to use nullable types as a sugar for Has and Clear methods?

github-actions[bot] commented 1 month ago

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

kluever commented 1 month ago

Keep active.