Use custom @NonNull/@Nullable annotations


I’m trying to use my own @NonNull/@Nullable annotations, but rules like RSPEC-2637 are not triggered. It’s a bit confusing to me since the annotations I wrote look just like Spring’s NonNull and Nullable annotations, which work perfectly fine with SonarLint. Am I missing something? Any insight on how this works would be deeply appreciated!

To add a bit more context, I actually wanted to write my own package-level annotations for null-safety, just like Spring’s NonNullApi and NonNullFields annotations. But when that didn’t work, I tracked the issue to the point where I could not even use my own @NotNull annotation.

The main reasons for using custom annotations are:

  • Spring annotations work great, but if I’m not using Spring (when writing a library, for example), it won’t make sense to add the whole Spring dependency to be able to use a few annotations
  • I would like my package-level annotation to apply to all targets (not just fields, parameters, methods). Would that work with SonarLint?
  • Also, I wrote a small Gradle plugin to automatically add all the files to the project, and it lets you choose which annotation(s) to add to the packages. It would be great if SonarLint can check for any null-safety annotation that anyone would wish to use, as long as it has the javax.annotation.Nonnull annotation (or its implementation, maybe?).

If anyone would like to check the Gradle plugin, here’s the link: strict-null-check :slightly_smiling_face:

I really appreciate any help you can provide.


Hello @JoseLion

From this more recent post, I can see that you now understand way better how we deal with Nullable annotations.

Did you manage to find answers to your questions in between?

Hi @Quentin!

Sorry for the late response, and thanks a lot for your answer (here and the mentioned post :slightly_smiling_face:)

Yep, now I have a better idea of how it works, and I think I found the answers for most of my questions too, thanks a lot!

Just one last question, I noticed that when the annotations are checked, there’s access to the annotation metadata, right? Wouldn’t this allow to actually check the annotation implementation and metadata instead of just checking for specific annotations burn into the code?

I understand this would need a big refactor, and I might be missing something too :sweat_smile: but I’d like to know if it’s possible and/or why this approach was not used (or if there are any plans to going this way). IMO, I think it would be great a great feature to be able to use custom nullability annotations :slightly_smiling_face:

Thanks again for the support!


If I understand correctly, your question is about supporting “meta-annotations” themselves annotated with a known Nullable annotation?

In fact, we are already supporting this… inconsistently, only in a few rules. :frowning:
When investigating this question, I realized that our helper class about nullable annotations became quite messy with time. I created a ticket (SONARJAVA-3795) to eventually clean everything and consistently support meta-annotations.

Thank you for raising this interesting point.

1 Like

Yep, that’s what I meant. Looking at the ticket you created makes it even clearer. :slightly_smiling_face:
So maybe supporting “meta-annotations” for nullness rules won’t be as much work/refactor as I initially imagined. That’s great news!

I’m glad I could help around this, and I’ll be looking forward to this awesome improvement.

Thanks again for the great support.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.