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):

  1. Must-use-result / May-ignore-result #200
  2. Must-close-returned-resource
  3. Method should be inlined
  4. Type parameter is co(ntra)variant #72
  5. Parameter must be compile-time constant
  6. Element is used dynamically (don't report as unused)
  7. Parameter requires argument type be "compatible" with given type
  8. Parameter names are published API
  9. 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.

  1. A common and powerful-enough format for external annotation overlay files ("stub files")
  2. A shared single-source-of-truth repository for these overlay files covering JDK APIs
  3. Standardized suppression strings #55
  4. Libraries to interpret JSpecify information for various code-inspecting APIs (reflection; javac mirrors; PSI?) #220
  5. 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.

  1. Add use-site nullable types to the Java language.
  2. Null-annotate the JDK class libraries.
  3. If we do design an overlay-file format as mentioned, could we promote that to OpenJDK?