RFR: 8155591: Misleading warning when not overriding close method in interface extending AutoCloseable [v2]

[Jan Lahoda]

On Tue, 23 Sep 2025 17:19:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler generates a warning if you declare a `close()` method that throws any supertype of `InterruptedException` in a class or interface extending `AutoCloseable`. This is because suppressed `InterruptedException`'s are likely to lead to misbehavior at runtime.
>> 
>> However, this feature also generates a warning due to `AutoCloseable.close()` itself, if you simply inherit it. For example:
>> 
>> $ cat MyClass.java
>> public interface MyClass extends AutoCloseable {
>> }
>> $ javac -Xlint:try MyClass.java
>> MyClass.java:1: warning: [try] auto-closeable resource MyClass has a member method close() that could throw InterruptedException
>> public interface MyClass extends AutoCloseable {
>>        ^
>> 1 warning
>> 
>> The warning is not useful because `AutoCloseable.close()` is abstract and so it's going to be some other class' job to deal with the throws clause.
>> 
>> This change prevents `AutoCloseable.close()` itself from triggering the warning in a class declaration. We preserve the existing behavior in which a warning is generated at the use site (i.e., at the try-with-resources statement).
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8155591 to get recent build fixes.
>  - Don't warn about AutoCloseable.close() itself throwing InterruptedException.

Makes sense to me. I think it would be useful if the tests would be enhanced to cover the case where the `close` method declaration in non-AutoClo does actually `Exception`/`InterruptedException`. I found `InterruptedExceptionTest.java`, but as that's a combo test, it is harder to see a sensible warning is produced on a sensible place.

Regarding sensible place, it would be possible to produce a warning specifically at the problematic `close` method (if it is declared in the given class, and not inherited) using `TreeInfo.diagnosticPositionFor`, but it is not so easy in this case - among other things, the warning would probably need a different wording. Up to you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27062#issuecomment-3485318048