typetools / typetools/checker-framework

[dereference.of.nullable] on final field access in closure

Open
#4,873 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

import java.util.function.Consumer;

import org.checkerframework.checker.nullness.qual.Nullable;

class CF {

    private final @Nullable Ref ref;

    CF(@Nullable Ref ref) {
        this.ref = ref;
    }

    void fun(CF other) {
        if (this.ref != null && other.ref != null) {
            this.ref.apply(arg -> other.ref.fun());
        }
    }

    static class Ref {
        void fun() {}
        void apply(Consumer<Void> c) { c.accept(null); }
    }
}

Running the default NullnessChecker

checker/bin/javac -processor org.checkerframework.checker.nullness.NullnessChecker CF.java

returns the following false-positive

CF.java:[15,39] error: [dereference.of.nullable] dereference of possibly-null reference other.ref

other.ref shouldn't be null at this point because nullness has been checked before and the field is final so it can't be re-assigned by any possible side-effects. I tested against checkerframework 3.17.0 and Java 8.

This issue might be related to #4872 but here, the nullness is checked directly (instead of a result of dataflow) and the access takes place in a closure rather than an inline block.

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 CF.java reproducer and run the listed NullnessChecker command on Java 8 to confirm the false positive. Trace how the checker handles the final other.ref field across the lambda in fun, considering the related behavior in issue #4872. Done means the example compiles without the erroneous dereference.of.nullable diagnostic while genuine nullable dereferences remain reported.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
devtools
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.