typetools / typetools/checker-framework

RLC inference with a private finalizer method

Open
#6,989 1 comment 0 reactions 1 assignee View on GitHub

@iamsanjaymalakar is already working on this.

Since Mar 13, 2025.

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

Description

When using Resource Leak Checker (RLC) inference, private finalizer methods that are invoked internally can lead to incorrect or incomplete inference results. Specifically, the inference mechanism does not annotate the enclosing class with @InheritableMustCall because the finalizer method is private, causing CF RLC to emit warnings like:

The enclosing element _ has an empty @MustCall annotation.

Consider this minimal example:

class Foo implements Runnable {

    @Owning
    private final FileWriter fileWriter;

    public Foo(File file) throws IOException {
        this.fileWriter = new FileWriter(file);
    }

    @EnsuresCalledMethods(value = { "this.fileWriter" }, methods = { "close" })
    private void close() {
        try {
            fileWriter.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public void run() {
        close();
    }
}

Here, the inference algorithm correctly identifies the finalizer method (close) as releasing fileWriter. But it does not infer an @InheritableMustCall annotation on Foo due to the close method's visibility (private). This results in the mentioned warning, and a missing resource-management specification.

To handle this case the possible correct behaviors I can think of:

  1. Inferring the necessary @EnsuresCalledMethods annotation on the caller method (run() in this example). But as the close method does take an @Owning paramter as an input, this is not happenning currently.
@EnsuresCalledMethods(value = { "this.fileWriter" }, methods = { "close" })
public void run() {
    close();
}
  1. Not inferring ownership annotations (@EnsuresCalledMethods) on private finalizer methods without parameters that are not exposed externally.

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.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.