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:
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 Annotationsin the right panel - Add
lombok.NonNullin theNotNull annotationslist - Rebuild your project
You should now see the warnings in your editor
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!
Top comments (5)
Such an annotations are mostly useless, as they don't change way we're writing code nor they are checked by compiler.
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 🙂
It's somewhat worse than useless, since it may give false feeling of safety. There is an alternative approach described here.
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).
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.