@Nonnull vs @NonNull

[stephanos]

Hello!

We are big fans of Lombok and mostly use it for data and value objects at the moment. 

Recently, we decided to leverage our IDE more by adding the javax.validation.Nonnull annotations to method parameters that are never supposed to be null. We also decided to enforce this at runtime by adding an explicit checkNotNull() (Guava) check to the method. We are aware of Lombok's @NonNull annotation - but it is not picked up by IntelliJ to provide warnings. That means that currently in order to get the IDE warnings and the runtime null checks, we'd need to annotate a parameter with @Nonnull and @NonNull.

So long story short, would it be possible for us to extend Lombok in a way that it generates runtime null checks for parameters annotated with @Nonnull?

Regards

Stephan

[pbihler]

Hi!

You can duplicate the two HandleNonNull classes (in the lombok.eclipse.handlers and lombok.javac.handlers) and made them extend Eclipse/JavacAnnotationHandler<javax.annotation.Nonnull>. In addition, you might want to skip the primitive test in your copy (if you like).

The "clean" way would be to refactor the lombok HandleNonNull classes, so that the "handle" method only calls a public static "handleNonNullAnnotation" method, which does all the real work. Then, your custom handlers would be reduced to:

@DeferUntilPostDiet
@ProviderFor(EclipseAnnotationHandler.class)
@HandlerPriority(value = 512)
public class HandleJavaXNonNull extends EclipseAnnotationHandler<javax.annotation.Nonnull> {

    @Override public void handle(AnnotationValues<Nonnull> annotation, Annotation ast, EclipseNode annotationNode) {
        HandleNonNull.handleNonNullAnnotation(annotation,annotationNode);
    }

}

@Reinier: Anything which speaks against including this in the official lombok? Or at least refactor the HandleNonNull classes as sketched out and provide a short tutorial of how to implement HandleJavaXNonNull and siblings as simple custom handlers?

Pascal

[Martin Grajcar]

I'm pretty sure that lombok (partly) ignoring foreign @Non[Nn]ull annotations is by design. The problem is that it often means something like "not null, except when ..." and throwing could be a disaster.

However, with lombok configuration, there can be an option to switch this on. I guess, it should be easy as lombok used to treat all non-null annotations like its own.

[Roel Spilker]

Yes, in the beginning we did throw NPE on Nonnull, but we got rid of it due to unexpected behavior. But now we have the lombok config system we have a way to opt-in.

On Thu, Mar 10, 2016 at 3:58 PM, Martin Grajcar <maaar...@gmail.com> wrote:

I'm pretty sure that lombok (partly) ignoring foreign @Non[Nn]ull annotations is by design. The problem is that it often means something like "not null, except when ..." and throwing could be a disaster.

However, with lombok configuration, there can be an option to switch this on. I guess, it should be easy as lombok used to treat all non-null annotations like its own.

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pbihler]

Great!

Can we change the HandleNonNulls to react on different Non[Nn]ull annotations (and the break on negative config) or do we have to implement a handler for each? We have to include jsr305.jar and siblings at least into the test libs, istn't it?

[omickron]

Are there any plans to do it? Or may be there's a ticket for this request?

четверг, 10 марта 2016 г., 19:30:38 UTC+3 пользователь Roel Spilker написал: