Community
Participate
Working Groups
BETA_JAVA7 The spec for AutoCloseable.close() says: * <p>Note that unlike the {@link java.io.Closeable#close close} * method of {@link java.io.Closeable}, this {@code close} method * is not required to be idempotent. In other words, * calling this {@code close} method more than once may have some * visible side effect, unlike {@code Closeable.close} which is * required to have no effect if called more than once. Hence when a user is explicitly closing a resource of type AutoCloseable, or closing it more than once in a try with resources block, we can give a warning to the user. class X{ void foo() throws Exception { try (FileInputStream fis = new FileInputStream) { fis.close(); // new warning here } finally { } } }
The spec also says * However, implementers of this interface are strongly encouraged * to make their {@code close} methods idempotent. So, I would say that this warning is a bit of overkill.
(In reply to comment #1) +1, wouldn't do that.
If close() is indeed idempotent an explicit close within t-w-r is not dangerous but simply unnecessary code. Given the infra structure from bug 349326 implementing such warning would be close to trivial. So I guess the most relevant overhead would be the configurability (CompilerOptions, JavaCore, @SuppressWarnings, UI)? Just let me know if there's still interest in this warning.
(In reply to comment #3) > Given the infra structure from bug 349326 implementing such warning would > be close to trivial. So I guess the most relevant overhead would be the > configurability (CompilerOptions, JavaCore, @SuppressWarnings, UI)? > > Just let me know if there's still interest in this warning. Yes currently I don't feel very strongly about having this, but just filed a bug to gather other's opinions. Surely, if the infrastructure from bug 349326 makes it simple, we can think about having this for 3.8 or later
Can we reassess this feature based on the fix made for bug 349326 ?
I don't think the warning itself is too interesting to be shown in the UI. However, if the warning is not too hard to implement JDT UI could use the warning internally in a clean up to get rid of unnecessary close() invocations.
I think this should be closed as WONTFIX. The comments make for slightly confusing reading: comment# 0 javadoc citation is actually a case for NOT issuing the warning, but it requests it. comment#1 citation actually strengthens the case for the warning, but the end argument is against it.
