DEV Community

loading...

Configure IntelliJ to show warnings for Lombok's @NonNull

gdaniel profile image Gwendal Daniel ใƒป1 min read

Lombok is a library I like to use in my projects to limit boilerplate code and focus on the core logic of my applications. I am using the IntelliJ plugin to integrate Lombok annotation processing with my IDE, for example to enable auto-completion of methods generated from @Getter/@Setter.

While this works pretty well, I regularly find myself searching resources on how I can configure Intellij to show warnings when I provide a null value to a method argument annotated with @NonNull. Since a picture is worth a thousand words here is what I try to achieve:

Missing warning in IntelliJ Editor

Since I spent some time figuring this out today I'll post my solution here in case anyone is wondering how this can be done (and also as an archive I can retrieve later ๐Ÿ˜…):

  • Open File -> Settings
  • Navigate to Editor -> Inspection -> Java -> Probable bugs -> Nullability problems -> @NotNull/@Nullable problems
  • Click on Configure Annotations in the right panel
  • Add lombok.NonNull in the NotNull annotations list
  • Rebuild your project

You should now see the warnings in your editor
IntelliJ printing the warning with Lombok annotation

You may have noticed the naming error in the warning pop-up ("@NotNull" instead of "@NonNull"). I didn't look into it, let me know if you have a solution for that!

Discussion (5)

pic
Editor guide
Collapse
siy profile image
Sergiy Yevtushenko

Such an annotations are mostly useless, as they don't change way we're writing code nor they are checked by compiler.

Collapse
gdaniel profile image
Gwendal Daniel Author

I'd say they are interesting for documentation, I think an annotation is way more explicit than an obscure sentence in the Javadoc.
With a good IDE integration you get warnings/errors "at design time", true it's not checked by the compiler but it still points out potential issues.
I don't have to deal with null checks since they are automatically generated.

It's clearly not ground breaking but I wouldn't say useless ๐Ÿ™‚

Collapse
siy profile image
Sergiy Yevtushenko

It's somewhat worse than useless, since it may give false feeling of safety. There is an alternative approach described here.

Thread Thread
gdaniel profile image
Gwendal Daniel Author

Thanks for the pointer, Optional (or similar constructs) are indeed a safer solution, at least for return types.
For method parameters I don't think they really provide any additional safety: you basically have to check if the provided Optional is null. It would be nice to have auto boxing of null into Optional, but as far as I know it's not the case (and I guess there are good reasons for that).

Thread Thread
siy profile image
Sergiy Yevtushenko

As mentioned in the article, this is a convention. To make it work it's enough to get rid of all explicit null values in code. This condition is much easier to check (search over all code). From my experience I can tell that not using null in code is an easy to get used to quite quickly.
With this convention nulls may appear only from external libs/code, but habit to create safety wrappers for such code also grows quickly. There is also similar approach to handling errors without using exceptions. Together these approaches result to concise, expressive and safe code, which is easy to write, read, test and maintain.