NullPointerException when using @lombok.NonNull on field

[shollander]

What steps will reproduce the problem?

Given the following class:

import lombok.Value;
import lombok.NonNull;

@Value
public final class MyData() {
    @NonNull
    private final String something;
}

The following test will fail with a NullPointerException:

public class MyDataTest {
    @Test
    public void testEquals() {
        EqualsVerifier.forClass(MyData.class)
            .verify();
    }
}

What error message or stack trace does EqualsVerifier give?

java.lang.AssertionError: NullPointerException

What did you expect?

Test to pass

Which version of EqualsVerifier are you using?

2.1.5

Please provide any additional information below.

Using Project Lombok (https://projectlombok.org/mavenrepo/index.html)
The @NonNull annotation will generate a NPE when trying to set the field to a null value. EqualsVerifier should not be attempting to set fields to null when they are marked as NonNull. In this case since the field is marked as final an NPE will be thrown by the constructor. I can also make everything non-final and use @Data instead of @Value on the class. In that case an NPE will be thrown by the setter also. Either way EqualsVerifier does not work.

[jqno]

Hi,

Thanks for reporting this. Unfortunately, I can't reproduce your issue: for me it works fine.

I've created a small GitHub project containing your code: https://github.com/jqno/equalsverifier-issuerepro/tree/issue-153 (Note the branch name). Could you please tweak it so that it produces the NPE you describe?

Thanks!

[shollander]

Hi,

I don't have write access to that project so I can't upload my changes. But I have been playing around with it and I believe I have discovered the issue. The error only occurs when the lombok is not available on the runtime classpath (which is the standard way of using lombok since it is only needed at compile time). I don't believe it is possible to reproduce it in a single module project using mvn since provided scope is also present for tests. However it is easy to reproduce with gradle. Just add the following file to the project root and run gradle build

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    testCompileOnly group: org.projectlombok, name: lombok, version: '1.16.10'

    testCompile group: 'junit', name: 'junit', version: '4.12'
    testCompile group: nl.jqno.equalsverifier, name: equalsverifier, version: '2.1.5'
}

[jqno]

Hi,

Thanks for the Gradle script, I've been able to reproduce the issue now.
EqualsVerifier indeed tries to resolve the class for Lombok's NonNull annotation, which is impossible because it's not there.

I don't have a solution for you yet, but I'll let you know when I do. In the mean time, I suppose the only ways to work around this issue is to have Lombok on your classpath after all, or to use a different NonNull annotation.

[shollander]

Ok thanks for your help.

This issue is not really specific to Lombok, I just happened to discover it while using Lombok. Annotations are just metadata and not usually required to be on the classpath.

[jqno]

I just released version 2.1.6, which fixes this issue.

[shollander]

Thanks for the quick fix!

[topr]

@jqno it seems the issue is back.
With lombok setup at a build file taken from theirs docs:

compileOnly 'org.projectlombok:lombok:1.18.8'
annotationProcessor 'org.projectlombok:lombok:1.18.8'

The same problem happens. It's sufficient changing compileOnly to implementation to 'fix' it.
This would carry the jar into any app packaging though.

[jqno]

Thanks for reporting this. Not sure if it's really the same issue, but I managed to reproduce it. I'll let you know when I have a fix.

[jqno]

Hm, I thought I'd reproduced the issue yesterday and when I tried again today, it worked fine.

@topr can you take a look at https://github.com/jqno/equalsverifier-issuerepro/tree/issue-153-2 (note the branch: issue-153-2) and see if it reflects your situation?

I run gradle clean test from the command-line, that should trigger the issue, right?

[jqno]

I gave it another try today, still can't reproduce it. I'm going to close this issue again. @topr, if you can reproduce it, feel free to re-open and show me how you did it: please provide a full project with offending test and build script. Take a look at the github project in my previous comment, which should make that easy.