long term roadmap - jspecify/jspecify GitHub Wiki
This page enumerates some future projects this group could take on. At present, we're committed to none of them.
Nullness support
Most of our attention is going toward trying to help our new nullness annotations succeed. It will also need ongoing improvements for a while.
Other annotation domains
Some candidates (no particular agreement on their value implied):
- Must-use-result / May-ignore-result #200
- Must-close-returned-resource
- Method should be inlined
- Type parameter is co(ntra)variant #72
- Parameter must be compile-time constant
- Element is used dynamically (don't report as unused)
- Parameter requires argument type be "compatible" with given type
- Parameter names are published API
- It makes any sense at all to "mock" this type
Note that we would be reluctant to add type-use annotations that could (even in theory) be addressed effectively with types instead.
Other aspects of static analysis
Our goal is to take the brakes off of static analysis technology. We believe we can do this, and provide much better experiences for users, if we build common solutions for much more than just annotations.
- A common and powerful-enough format for external annotation overlay files ("stub files")
- A shared single-source-of-truth repository for these overlay files covering JDK APIs
- Standardized suppression strings #55
- Libraries to interpret JSpecify information for various code-inspecting APIs (reflection; javac mirrors; PSI?) #220
- Analyzer plugin API to derive information that is normally annotation-based ("I know this method can't actually return null...")
Upstream
In some cases our work might serve to "incubate" features that eventually end up part of the Java platform.
- Add use-site nullable types to the Java language.
- Null-annotate the JDK class libraries.
- If we do design an overlay-file format as mentioned, could we promote that to OpenJDK?