Repository navigation
Tracking issue: making jspecify/jdk library models available to NullAway users #950
Description
This issue is for tracking remaining changes we need to make to use the jspecify/jdk library models with NullAway. We added some initial support for parsing source code and generating astubx files in #922, with support only for reading in @Nullable return types. (List below is quite incomplete for the moment)
- External Library Models: Adding support for Nullable upper bounds of Generic Type parameters #949
- Unify
InferredJARModelsHandlerandLibraryModelsHandler#1072 - Rename the Jar Infer Flags
JarInferEnabled,JarInferUseReturnAnnotations#940 - properly handle defaults for modeled
@NullMarkedclasses (unannotated types are@NonNull) External Library Models: Adding support for @Nullable Method parameters #1006 - scripts to generate an
astubxjar artifact that can be shipped to Maven Central - add a flag for using the new models separate from JSpecify mode?
- False-positive warning on Objects.requireNonNullElse #1493
Reacted by Samuel Nelson, Petr Portnov | PROgrm_JARvis, Subhramit Basu and Oleg Estekhin
Activity
Prototype implementation of javac plugin to serialize nullness annota…
Add a self-contained test case for #1157 (#1289)
Properly model AtomicReference.get() in JSpecify mode (#1298)
msridhar commentedon Nov 11, 2025
We've changed our approach here rather significantly. We're now using a
javacplugin to extract the nullness info out ofjspecify/jdk. #1333 is our latest work on this approach, and it seems to be the way we will go.test case for issue 1493 (#1496)
Add more modeling for Optional (#1613)
msridhar commentedon Aug 21, 2026
This is now fixed on the master branch, underneath a flag that is off by default (since it causes a bunch of new warnings in typical projects). There are potentially more minor issues to fix (like #1498) but for the most part this is done. So I'm going to close this issue! Please file follow-ups where things don't work.