Потенциальная проблема с утечкой ресурсов

Здесь вы получаете предупреждение Потенциальная утечка ресурсов, которое отключено по умолчанию, а не обычное предупреждение Утечка ресурсов, которое включено по умолчанию. В отличие от предупреждения Утечка ресурсов, предупреждение Потенциальная утечка ресурсов будет отображаться, если вы не создаете AutoCloseable самостоятельно, а получаете его откуда-то и не закрывайте его ни явно, вызывая close(), ни неявно, используя try-with-resource.

Закрыт ли ресурс где-то, откуда вы его взяли, как в вашем случае, может быть вычислено для простых случаев, но не для всех случаев. Это та же проблема, что и проблема остановки. Например, создание AutoCloseable или его закрытие может быть делегировано куда-то, где оно делегируется снова, и так далее, и если есть if, switch или цикл, все ветви должны быть соблюдены, чтобы быть уверенным. .

Даже в вашем простом на вид примере все не так просто. Делая единственный конструктор закрытым, вы предотвращаете возможность расширения класса, иначе можно было бы переопределить close() без вызова super.close(), что приведет к тому, что target.close() никогда не будет вызван. Но так как private OutputStream target; не final, все еще может иметь место реальная утечка ресурсов, как показано ниже:

public static void main(String[] args) throws Exception {
    try (MyWriter w = MyWriter.toPath(Path.of("out.txt"))) {
        // …
        OutputStream target = w.getTarget();
        w.target = new FileOutputStream("out2.txt");
        // …
    }
}

Таким образом, компилятор должен будет проверить, кроме того, что класс не может быть переопределен, если поле, содержащее внутреннее AutoCloseable, является либо final, либо privat и эффективно окончательным (устанавливается только при инициализации), и что внутреннее AutoCloseable будет закрыто в close() внешнего AutoCloseable .

Подводя итог, если вы не генерируете ресурс самостоятельно, а получаете его откуда-то, нет никакой гарантии, что компилятор сможет за ограниченное время вычислить, будет ли он закрыт (см. проблема остановки). Для таких случаев существует предупреждение Потенциальная утечка ресурсов в дополнение к предупреждению Утечка ресурсов, которое можно отключить отдельно и оно отключено по умолчанию.

Решение на основе аннотаций?

@SuppressWarnings предназначена для подавления именованных предупреждений компилятора в аннотированном элементе. Но в этом случае здесь потребуется аннотация, которая сообщает компилятору, что возвращаемый AutoCloseable не нужно закрывать, подобно @SafeVarargs или в нулевые аннотации. Насколько мне известно, такой аннотации еще не существует, по крайней мере, в системной библиотеке. Чтобы использовать такую ​​аннотацию, нужно было бы сначала добавить в проект зависимость, содержащую эту аннотацию (точно такая же ситуация, как и для нулевых аннотаций, которые, к сожалению, до сих пор не являются частью системной библиотеки, может быть потому, что javac делает в настоящее время не поддерживает нулевой анализ на основе аннотаций, в отличие от компилятора Eclipse и других IDE и инструментов).

Также должно быть решение для случаев, подобных следующему, где входным параметром определяется, нужно ли закрывать возвращаемое значение или нет (возможно, с помощью другой аннотации):

public static BufferedOutputStream toBufferedOutputStream(OutputStream outputStream) {
    return new BufferedOutputStream(outputStream);
}

Итак, во-первых, такие аннотации должны существовать (лучше не специфичные для Eclipse и как часть системной библиотеки), чтобы Eclipse могла их поддерживать.

Решение для данного примера

В качестве решения не подвергайте target воздействию, например, обернув его и расширив от OutputStream:

public class MyWriter extends OutputStream {
    public static void main(String[] args) throws Exception {
        try (MyWriter w = MyWriter.of(Path.of("out.txt"))) {
            // …
            w.flush();
            // …
        }
    }

    @SuppressWarnings("resource")
    public static MyWriter of(Path target) throws IOException {
        OutputStream s = Files.newOutputStream(target);
        return new MyWriter(s);
    }

    private final OutputStream target;

    private MyWriter(OutputStream target) {
        this.target = target;
    }

    @Override
    public void close() throws IOException {
        target.close();
    }

    @Override
    public void write(int b) throws IOException {
        target.write(b);
    }
    
    @Override
    public void flush() throws IOException {
        target.flush();
    }
}

Или еще лучше:

public class MyWriter {
    
    public static void main(String[] args) throws Exception {
        MyWriter.writeToFile(Path.of("out.txt"), w -> {
            try {
                // …
                w.flush();
                // …
            } catch (IOException e) {
                // error handling
            }
        });
    }

    public static void writeToFile(Path target, Consumer<OutputStream> writer) throws IOException {
        try (OutputStream out = Files.newOutputStream(target);) {
           writer.accept(out);
        }
    }

}