typetools / typetools/checker-framework

Feature request: optimistic mode for unannotated class files

Open
#2,262 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Java
Stars
1.1k
Forks
440
Avg merge
1d 12h
Merged PRs (30d)
134

Description

This is following up on a 2-year-old thread from the Checker Framework mailing list. Consider the following example:

T1.java:

public class T1 {
    public static void checkStr(String s) {
      // uncommenting this line doesn't seem to make a difference,
      // but including just in case
      // s.toString();
    }
}

T2.java:

public class T2 {
    public static void main(String[] args) {
        T1.checkStr(null);
    }
}

If we compile T1.java without the Checker Framework, and then run the Nullness Checker on when compiling T2, we get an error that the call T1.checkStr(null) is passing @Nullable where @NonNull is expected. The manual does not make fully clear what behavior is expected for unannotated class files, but the thread linked above indicates that both parameters and return values are treated as @NonNull for such code.

It would be useful to have an "optimistic mode" for unannotated class files, where returns are assumed to be @NonNull but parameters are assumed to be @Nullable. In fact, maybe that should be the default?

If the current default is desired, it would be great if it could be documented somewhere in the manual.

Possibly related to #12

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the T1.java and T2.java reproduction, then read the linked Checker Framework mailing-list thread and the manual section describing unannotated class files. Determine whether optimistic mode should be optional or the default, and whether the current behavior should instead be documented. Done means the chosen behavior is specified and the reproduction reflects the agreed parameter and return-value assumptions.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.