GSoC 2026 idea: closing Nullness soundness gaps in the annotated JDK

[shubham kapoor]

Hello,

I am Shubham, preparing a GSoC 2026 proposal for the Checker Framework.

I have been doing a case study on JDK nullness annotations in typetools/jdk. While
reviewing the repository, I noticed that several JDK classes contain Checker
Framework annotations (e.g., @Pure, @Nullable on equals) but are missing
@Nullable on methods documented as being able to return null, and also lack
@AnnotatedFor({"nullness"}) to mark them as fully specified for nullness.

I tested this on ConcurrentSkipListMap locally - methods like lowerEntry(),
floorEntry(), and ceilingEntry() are documented to return null but lacked
@Nullable annotations. Adding the missing @Nullable annotations exposed
null-dereference issues that were previously missed (2 errors to 6 in my test
client), confirming a real soundness gap.

I also noticed comments in SourceChecker.java about future work toward more
conservative handling of unannotated bytecode, where @AnnotatedFor would play a
larger role in distinguishing reviewed library specifications. This reinforced
the value of completing these annotations now.

I am considering this project focused on systematically completing
nullness annotations and adding @AnnotatedFor({"nullness"}) for a small,
high-impact subset of JDK packages (starting with java.util.concurrent, and
possibly others if appropriate), with validation via concrete client case
studies.

Before going further, I wanted to check:

- Is this a useful and currently relevant direction for the project?
- Are there specific JDK areas where this effort would be most valuable?

Thanks,
Shubham