Lombok issue with @Setter and @Nullable

4,263 views
Skip to first unread message

cfnz

unread,
Feb 9, 2016, 5:00:28 AM2/9/16
to Project Lombok
Maybe a bug?

From the Lombok @Setter fine print: Any annotations named @NonNull (case insensitive) on the field are interpreted as: This field must not ever hold null. Therefore, these annotations result in an explicit null check in the generated setter. Also, these annotations (as well as any annotation named @Nullable or @CheckForNull) are copied to setter parameter and getter method.

However, given the following example class:

import org.eclipse.jdt.annotation.NonNullByDefault;
import org.eclipse.jdt.annotation.Nullable;

import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
@NonNullByDefault
public class TestClass {
   
private String testNonNull = "";

   
@Nullable
   
private String testNullable;
 
   
@Nullable
   
private String testNullable2;
 
  public void setTestNullable2(@Nullable String testNullable2) {
       
this.testNullable2 = testNullable2;
   
}
}

Then, using it you get the following:
public class Main {
   
public static void main(String[] args) {
       
TestClass testClass = new TestClass();
   
        testClass
.setTestNonNull(null);   // Right - Eclipse says: Null type mismatch: required '@NonNull String' but the provided value is null
        testClass
.setTestNullable(null);  // Wrong - Eclipse says: Null type mismatch: required '@NonNull String' but the provided value is null
        testClass
.setTestNullable2(null); // Right - Eclipse does not complain.
   
}
}


It seems contrary to the small print, setTestNullable and setTestNullable2 should be treated the same way?


Regards

Colin


Attention:

The information in this email and in any attachments is confidential. If you are not the intended recipient then please do not distribute, copy or use this information. Please notify us immediately and then delete the message from your computer. Any views or opinions presented are solely those of the author.

cfnz

unread,
May 13, 2016, 7:24:28 PM5/13/16
to Project Lombok
We still have this issue.

Basically this makes using Eclipse with Null Type Annotations and Lombok @Setter's pointless (or more specifically with nullable fields).

In our app, lots of things are flagged as warnings (when turning warnings on for null type analysis, which is what you want or you would not bother with them). Unfortunately we have gone through a fair chunk of code adding @Setter's and using the version 2 of the Eclipse Null Type Annotations before realising this (at first we thought they were legit warnings, but they are not).

Therefore we are thinking about not using Lombok @Setter which is a great shame (we could just decide not to use it for any field that could be Null - people might say good - use Optional instead, but most of this is on JPA Entity fields, so I don't believe this is the recommended approach - maybe there could be a Lombok annotation turning a nullable field into an optional getter/setter? :-)).

Also note that for some reason, if you do a project clean on the above, the warning hints that are in the wrong will disappear. Only when you start editing the main class and save will all the hints reappear (only one is this example) - but for larger projects, or "projects using projects", a clean does not remove the wrongly placed hints.

Also note I have concluded it is something with Lombok as the testNullable2 uses a normal setter and Eclipse gets that right when you do a clean and after you do a save.

Thanks for any feedback... if I could find a work around, I will be happy!

Message has been deleted

cfnz

unread,
Jun 28, 2016, 1:27:48 AM6/28/16
to Project Lombok
Hi,

Still battling this issue and team not that keen to change to Null type checking with Lombok with it...

Note that delombok does what it should, so it seems an issue with Eclipse integration...

Screenshot shows the issue:


Is this worth posting as an issue? (or is it just us...) 
Reply all
Reply to author
Forward
0 new messages