Default option when we don't provide -Xep:NullAway:ERROR is not working

[hemanthbsridhar]

Bug :

nullaway Version : 0.8.0

According to the documentation, the default behaviour should show the problems as warnings.

when we don't provide '-Xep:NullAway:ERROR' or when we provide '-Xep:NullAway:WARN', the issues are not coming as warning in the logs.

This works fine when '-Xep:NullAway:ERROR' is provided

BUILD.bazel

java_library(
    name = "module",
    srcs = glob(["src/main/java/**/*.java"]),
    visibility = ["//our-service:__subpackages__"],
    plugins=['nullaway'],
    javacopts=[
    	    #'-Xep:NullAway:ERROR',
    		'-XepOpt:NullAway:AnnotatedPackages=io.bla',
    	],
    deps = shared_dependencies,
)

Documentation

[msridhar]

What build system are you using? Can you confirm that warnings from javac and other Error Prone checkers are coming through? And any particular reason you are on NullAway 0.8.0 and not the latest release (0.10.14)? 0.8.0 is a couple years old.

[hemanthbsridhar]

• Build management tool we are using is bazel
• I can confirm that warnings from javac and other Error Prone checkers are coming through
• When I use 0.10.14 I get the below error

java.util.ServiceConfigurationError: com.google.errorprone.bugpatterns.BugChecker: Provider com.uber.nullaway.NullAway could not be instantiated
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:582)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:804)
	at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:722)
	at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1395)
	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:52)
	at com.google.errorprone.scanner.ScannerSupplier.fromBugCheckerClasses(ScannerSupplier.java:71)
	at com.google.errorprone.ErrorPronePlugins.loadPlugins(ErrorPronePlugins.java:47)
	at com.google.errorprone.ErrorProneAnalyzer.lambda$scansPlugins$0(ErrorProneAnalyzer.java:77)
	at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:183)
	at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:152)
	at com.google.devtools.build.buildjar.javac.plugins.errorprone.ErrorPronePlugin.postFlow(ErrorPronePlugin.java:116)
	at com.google.devtools.build.buildjar.javac.BlazeJavaCompiler.flow(BlazeJavaCompiler.java:115)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1365)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:960)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:147)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
	at com.google.devtools.build.buildjar.javac.BlazeJavacMain.compile(BlazeJavacMain.java:138)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileSources(SimpleJavaLibraryBuilder.java:49)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:110)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:118)
	at com.google.devtools.build.buildjar.BazelJavaBuilder.build(BazelJavaBuilder.java:105)
	at com.google.devtools.build.buildjar.BazelJavaBuilder.parseAndBuild(BazelJavaBuilder.java:85)
	at com.google.devtools.build.lib.worker.WorkRequestHandler$WorkRequestHandlerBuilder.lambda$new$0(WorkRequestHandler.java:265)
	at com.google.devtools.build.lib.worker.WorkRequestHandler$WorkRequestCallback.apply(WorkRequestHandler.java:231)
	at com.google.devtools.build.lib.worker.WorkRequestHandler.respondToRequest(WorkRequestHandler.java:427)
	at com.google.devtools.build.lib.worker.WorkRequestHandler.lambda$startResponseThread$1(WorkRequestHandler.java:384)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.NoClassDefFoundError: org/checkerframework/nullaway/dataflow/cfg/node/MethodInvocationNode
	at com.uber.nullaway.NullAway.<init>(NullAway.java:283)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:780)
	... 26 more
Caused by: java.lang.ClassNotFoundException: org.checkerframework.nullaway.dataflow.cfg.node.MethodInvocationNode
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:476)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 32 more

[msridhar]

To fix the 0.10.14 crash, you need to have the org.checkerframework:dataflow-nullaway:3.38.0 jar in your processor path (it's a dependency in the pom file but I guess Bazel doesn't look at that). Can you try adding that to see if it fixes the problem?

I see our instructions for running NullAway with Bazel are quite outdated. It'd be good to update them, once we figure out these issues.

[hemanthbsridhar]

Adding org.checkerframework:dataflow-nullaway:3.38.0 resolved the issue but I still do not see the default warnings.
It works only when I provide '-Xep:NullAway:ERROR',

[msridhar]

@hemanthbsridhar unfortunately I am not a Bazel expert and so I don't really know what is going on. I can tell you error reporting in NullAway uses standard Error Prone APIs, so if you see warnings from other Error Prone checkers, you should also see them from NullAway. If you can create a standalone GitHub repo that reproduces the problem, we can try to investigate further.

[delanym]

Well I'm building with Maven and in my case I get output like [NullAway] dereferenced expression inputFile.getParent() is @Nullable as a [WARNING] even though I asked for -Xep:NullAway:ERROR

[msridhar]

For Maven (as for Bazel) a self-contained public example to reproduce would be helpful.

[delanym]

Do you have a counter-example? A template for me to tweak?

[msridhar]

For Maven hopefully something like this still works, with updated version numbers:

https://github.com/uber/NullAway/wiki/Configuration#maven

If you're using an Error Prone version more recent than 2.10.0 then the jdk8 stuff isn't relevant as recent Error Prone versions do not run on JDK 8.

[delanym]

I was working off that. Its a simple matter from my side: my other bugpatterns appear as I would expect, e.g. -Xep:EqualsHashCode:WARN comes as a warning and no longer fails my build. Therefore, the fault is with Nullaway's implementation. As I haven't yet tasted the benefits of this rule I'm not inclined to delve into its internals.

[msridhar]

I tested this myself and found that the version of the Maven Compiler Plugin is key. 3.10.1 is broken for printing warnings, but 3.11.0 works. I've updated our Maven example accordingly. Here is a sample repo where if you run mvn clean compile you will see a NullAway warning being printed (without failing the build).

Unfortunately this still doesn't help the Bazel issue. But for that one, I expect that, like this one, the issue is common to all Error Prone checks, not just NullAway. So I am going to suggest opening an issue on the Error Prone repo, and I will close this one. If you find evidence this is NullAway-specific, please re-open. And thanks for reporting this.