NullAway
NullAway copied to clipboard
-XepOpt:NullAway:UnannotatedClasses is not effective in maven
Im using NullAway in maven my configuration in pom.xml is below
Here is com.MyClass.java
package com;
import org.jetbrains.annotations.Nullable;
public class MyClass {
static void log(@Nullable Object x) {
System.out.println(x.toString());
}
static void foo()
{
log(null);
}
}
After "mvn clean compile" MyClass.java is still annotated by NullAway. idk why and could u plz help?
Could you edit your comment above and properly indent the pom.xml
? It's very hard to read as is. Thanks!
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5</version>
<configuration>
<compilerId>javac-with-errorprone</compilerId>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
<source>1.8</source>
<target>1.8</target>
<showWarnings>true</showWarnings>
<annotationProcessorPaths>
<path>
<groupId>com.uber.nullaway</groupId>
<artifactId>nullaway</artifactId>
<version>0.8.0</version>
</path>
<path>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
</path>
</annotationProcessorPaths>
<compilerArgs>
<arg>-Xep:NullAway:ERROR</arg>
<arg>-XepOpt:NullAway:AnnotatedPackages=com</arg>
<arg>-XepOpt:NullAway:UnannotatedClasses=com.MyClass</arg>
</compilerArgs>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-javac-errorprone</artifactId>
<version>2.8</version>
</dependency>
<!-- override plexus-compiler-javac-errorprone's dependency on
Error Prone with the latest version -->
<dependency>
<groupId>com.google.errorprone</groupId>
<artifactId>error_prone_core</artifactId>
<version>2.3.4</version>
</dependency>
</dependencies>
</plugin>
</plugins>
sry bro i tried to edit but not succeed, so i write my pom.xml here, thanks a lot again
Thanks. FWIW, your config doesn't look consistent with what was recommended for EP 2.3.4:
https://github.com/google/error-prone/blob/v2.3.4/examples/maven/pom.xml
Their config runs Error Prone as a javac plugin using -Xplugin:ErrorProne
. Just FYI, if it's working for you it's probably ok.
Regarding your issue, NullAway has the concepts of unannotated classes and excluded classes. If a class is unannotated, then calls into the class's methods from other classes will be treated with maximum permissiveness (all parameters assumed @Nullable
, all returns assumed @NonNull
). However, the code inside an unannotated class is still checked for NullAway errors. For an excluded class, the code inside the class does not get checked for NullAway errors, but its APIs are treated as annotated.
For your code, I think you want to mark the class as excluded, using -XepOpt:NullAway:ExcludedClasses
. Can you try that and see if it works?
I just realized that your Maven pom.xml
is probably based on our example which is out of date 🤦♂️ I will fix that now! (EDIT: it's updated.)
Hey I tried your new Maven pom.xml file but it cannot work properly for my project , and I also tried -XepOpt:NullAway:ExcludedClasses, it cannot work either. However, I just found if I use -XepOpt:NullAway:UnannotatedSubPackages for classes, it can work! Like if I use -XepOpt:NullAway:UnannotatedSubPackages = com.MyClass, MyClass.java would not be annotated. XD
@Supernova2014201970 I am unclear whether you want to treat MyClass
as excluded, unannotated, or both. I'm also unclear if this issue has anything to do with Maven (doesn't seem like it). If you could post a complete sample project on GitHub, along with expected and actual output, that would be helpful.
Hi @msridhar Regarding: https://github.com/uber/NullAway/issues/421#issuecomment-698441902
If a class is unannotated, then calls into the class's methods from other classes will be treated with maximum permissiveness (all parameters assumed @Nullable, all returns assumed @NonNull)
I think returns should be assumed also @Nullable
, not @NonNull
.
I think returns should be assumed also
@Nullable
, not@NonNull
.
The idea is to be maximally permissive with unannotated classes, to avoid excessive false positives in code we are analyzing. We are not aiming to report all possible issues related to unannotated code. Hence, we assume non-null returns.
This issue is long dormant so I am going to close it out.