Community
Participate
Working Groups
BETA_JAVA7 Add a compiler warning for methods that override AutoCloseable#close() and throw InterruptedException: * <p><em>Implementers of this interface are also strongly advised * to not have the {@code close} method throw {@link * InterruptedException}.</em> I don't think this warning needs to be configurable or suppressible by a special @SuppressWarnings token (except for "all"). Example: class ACloseable implements AutoCloseable { @Override public void close() throws IllegalArgumentException, InterruptedException { } }
Ayush, please follow up.
Load balancing - Satyam, please take up this item. Thanks.
low priority for me
(In reply to comment #3) > low priority for me Thanks for the input. Moving it out to 3.9 time frame.
See also https://bugs.openjdk.java.net/browse/JDK-7027157 I stumbled upon this when eclipse.jdt.core-run.javac-10 failed in ResourceLeakTests.testBug473317 saying: testBug473317: unused excuse org.eclipse.jdt.core.tests.compiler.regression.AbstractRegressionTest$JavacTestOptions$Excuse@f04b315 for compiler org.eclipse.jdt.core.tests.compiler.regression.AbstractRegressionTest$JavacCompiler@606f0f70 --- javac err: --- AutoCloseableEnhancedForTest.java:27: warning: [try] auto-closeable resource MyIterable<T> has a member method close() that could throw InterruptedException private static class MyIterable<T> implements Iterable<T>, AutoCloseable ^ where T is a type-variable: T extends Object declared in class MyIterable 1 warning -------------- regarding @SW & configurability: javac supports @SuppressWarnings("try") - so should we.
See also https://bugs.openjdk.java.net/browse/JDK-7148025 "javac should not warn about InterruptedException on the declaration of AutoCloseable itself"
And: https://bugs.openjdk.java.net/browse/JDK-8155591 "Suggestion: only report a warning for an actual declaration of a 'close' method; potentially, only for a non-abstract declaration (because an abstract declaration is just repeating the inherited signature of AutoCloseable)."
Bulk move out of 4.11
I've removed the 'plan' keyword because no target milestone was set. A plan bug must always have a target milestone. If you consider to set the 'plan' keyword again, make sure that the target milestone must match the release where it was originally planned. If the work was not finished, a follow-up plan bug for the next release must be created and the old one left in the NEW state. Not doing so would destroy the initial plan. The plan must reflect what has been delivered and what not. Also, please make sure that you only tag root/top-level bugs with 'plan'. Bug fixes or simple things must not get the 'plan keyword.
