Comments (8)
Thanks @JakeWharton , I don't thinks its supported yet.
Thanks @msridhar .
It's a real mix, as you'd expect in a large code base. I have a ton of Spring beans it's tripping on that are annotated with @Autowired
and @PostConstruct
and I need to add those annotations to the config and see how much that pairs things down.
Most of really nullable fields are in model objects which model JSON (where they are almost all nullable), or Hibernate database entities (where they are a mix). In both of these cases every field is private with a public getter/setter pair which would also need annotation. In both cases the fields have to start null and have empty constructors, and they may or may not be initialised inside the frameworks (Hibernate & Jackson).
Parameters are also a mix. But the vast majority of our methods are written defensively with null guards (due to bitter experience of NPEs!), so it would be useful to set the reverse default there for sure.
Lately the team has been writing a lot of Swift, Kotlin & (recent versions of) Typescript, and the non null enforcing in those languages really shows up how primitive the null checking is in Java (and our C++ code for that matter...). So I'm keen to make this happen.
Do you think that the code is encapsulated enough that changing the logic in nullnessFromAnnotations
in Nullness.java
would be enough? If so I might have a go at a fork to see if it works:
private static Nullness nullnessFromAnnotations(Element element) {
for (AnnotationMirror anno : NullabilityUtil.getAllAnnotations(element)) {
String annotStr = anno.getAnnotationType().toString();
if (isNullableAnnotation(annotStr)) {
return Nullness.NULLABLE;
}
}
return Nullness.NONNULL;
}
public static boolean hasNullableAnnotation(Element element) {
return nullnessFromAnnotations(element) == Nullness.NULLABLE;
}
from nullaway.
Hi @caseykulm, I won't be able to look more until next week, but could you open a separate issue in the @LateInitVar
support? That sounds like a good idea, but I think it's separate from this issue.
from nullaway.
I don't think it's supported yet, but you can annotate packages with Checker Framework's @DefaultQualifier
annotation to make the default nullable.
from nullaway.
Hi @jonnermut! We don't support this reversal at the moment, though with some work we could probably do it in the future. For the fields, are they in fact nullable and your code needs to have defensive null checks everywhere? Or is it that they are not null after initialization, but NullAway doesn't understand the initialization pattern? If it's the latter, and if there is some annotation on the fields or classes to indicate they are getting initialized in a special way, we could probably add support for that pretty easily. Parameters are a different story, and probably require something like flipping the default.
For adopting Error Prone gradually, you can try to use the new -XepExcludedPaths
option in EP 2.1.3 to exclude large chunks of your code base from all Error Prone checks, and then gradually allow checks on more code as it is ready. It'll still be painful, but less painful then trying to get all code passing the checks at once 😄
from nullaway.
@jonnermut feel free to give it a shot! I think the key issue is how NullAway should figure out whether a class has opted in to the default nullable treatment. I think we'll need to add support for something like @DefaultQualifier
, both at the class and package level. And also this should work whether a class is present as source code or in a jar file. Depending on how expensive the @DefaultQualifier
search is, we may need some caching as well. And we'll also have to figure out which non-null annotations to support 😄
FYI, I probably won't be able to look too much at this until after the holidays.
from nullaway.
Could this be solved by passing a custom annotation to the -XepOpt:NullAway:ExcludedFieldAnnotations
complication flag to not check certain fields?
To extend upon this, I was hoping to find a way to completely exclude a field marked with this custom annotation from any NullAway analysis, and not just initialization. I have a field that is both late initialized, and is nulled out after being used in many different functions. I would ideally like for it to not be nullable, but in the meantime it would be nice to not have to add a @SupressWarning("NullAway")
annotation to the method that nulls out this object (since it might have other fields I do want NullAway to run on).
from nullaway.
After discussing the extended use case above with a co-worker, we decided that wrapping the value in Optional
can handle the extended case.
from nullaway.
To help solve the original problem in this thread, and to even match Kotlin, a pre-baked @LateInitVar
annotation could be added to NullAway as an ExcludedFieldAnnotation.
from nullaway.
Related Issues (20)
- jdk Files false positive/wrong line HOT 3
- Update JSpecify package in docs HOT 1
- The combination of JSpecify + Lombok does not seem to work well HOT 6
- Method references of nullable instances are not detected HOT 1
- Detected NPE causes EP's Var rule to go nuts. HOT 5
- Validation of null in a switch-case with pattern matching does not work as expected. HOT 1
- False positive warning on switch statements with case null
- Build failure : 'options.compilerArgumentProviders.errorprone$0.name' is missing an input or output annotation. HOT 1
- Support org.apache.commons.lang3.StringUtils.isNotEmpty HOT 3
- Support for `collect()` in Streams API HOT 4
- Control flow analysis fails within a stream collector HOT 5
- Validation of null in a method used in a boolean expression does not work as expected. HOT 1
- `if (Foo.this.bar != null)` in nested class not properly analyzed HOT 1
- Rename the Jar Infer Flags `JarInferEnabled`,`JarInferUseReturnAnnotations`
- Variable checked non-null outside a `forEach` or `Stream` lambda triggers an error HOT 13
- `if` statement on a boolean does not prevent a dereferenced nullable error HOT 1
- Null `if` check and failing function to taken in account HOT 2
- Extract methods in StreamNullabilityPropagator
- ignoring generic Nullable on Supplier HOT 14
- Published NonNull Present HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nullaway.