Declaring a non-null return value?

Using VS Code and Java, I’m trying to set up a class that receives potentially null values, and verifies they are not null as part of instance construction. Here’s a simplified version (the real code uses a builder pattern).

public class Job {
   private @NonNull String name;

   public Job(@Nullable String jobName) {
      this.name = checkNotNull(jobName, "Name cannot be null");
   }
}

My checkNotNull() is…

public static <T> @NonNull T checkNotNull(@Nullable T value, @NonNull String message) {
   if (value == null)
      throw new NullPointerException(message);
   return (value);
}

On the this.name = ... assignment, SonarLint is reporting "name" is marked "org.eclipse.jdt.annotation.NonNullByDefault" but is set to null.sonarlint(java:S2637). How do I construct or annotate this so SonarLint realizes the return of checkNotNull() is @NonNull? Or am I misinterpreting the warning?

Thanks!

Hi Jason,

I can not reproduce, can you provide the imports to be sure about which @NonNull and @Nullable we are talking about? (ex: org.springframework.lang.NonNull and org.springframework.lang.Nullable)
And can you confirm that “checkNotNull” is not in the Job.java file?

Sorry for the delay getting back to you. Here is my best attempt at creating a reproduction case: GitHub - starkos/sonarlint-s2637: Replication case for SonarLint problem report

I’m not seeing the exact same behavior from this simplified version though. In my full codebase, SL behaves as described above. In this minimal example, I would expect SL to raise an issue on Job.java:14, where I’m assigning a @Nullable to a @NonNull, but I’m not getting one.

If I were getting one, I would expect the commented out checkNotNull() bit to solve it. That’s what I’m doing in the full codebase, and where I’m seeing the reported issue.

Does this help at all or just confuse the issue more?

Would it be possible to send the larger work-in-progress to you? It isn’t terribly large, and there is nothing particularly proprietary about it, especially in its unfinished state, but I’d still prefer not posting it to the internet at large. In the larger project it is reliably reproduced in both VS Code for Java and Eclipse. Disappointing that I get a different issue in my smaller reproduction case.