How is in Java the idempotence of the close() method of the Closeable interface ensured?

Question

The Closeable interface was introduced in Java 5 whereas the AutoCloseable interface came in Java 7 together with the try-with-resources statement. Closeable extends (since Java 7) the Autocloseable interface.

In the book OCA/OCP Java SE 7 - Programmer I & II Study Guide it says on page 399:

What happends if we call the close() multiple time? It depends. For classes that implement AutoCloseable , the implementation is required to be idempotent. Which means you can call close() all day and nothing will happen the second time and beyond. [...] For classes that implement Closeable , there is no such guarantee.

So according to this text, implementations of AutoCloseable need to be idempotent, and those of Closeable not. Now when I have a look at the documentation of the AutoCloseable interface at docs.oracle.com , it says:

Note that unlike the close method of Closeable , this close method is not required to be idempotent. In other words, calling this close method more than once may have some visible side effect, unlike Closeable.close which is required to have no effect if called more than once.

Now this is the opposite of what is written in the book. I have two questions:

(1) What is correct? The doc at docs.oracle.com or the book? Which of the two interfaces requires idempotence?

(2) No matter which one needs to be idempotent - am I right that Java has actually no way at all to ensure that it is idempotent? If so, the "requirement" of the close method to be idempotent is something that the programmer should do, but I can never be sure that someone who used the interface actually did do it, right? In this case the idempotence is merely a suggestion of oracle, correct?

Answer 1

1. Javadoc from Oracle is correct. Just an intuition why - AutoCloseable objects are used in try(){} (so called try with resources ) blocks, where close() is actually called automatically and only once; at the same time close() from Closeable interface method you always call manually and you can call it twice accidentally or to make your code easy to read. In addition - Closeable extends AutoCloseable and it shouldn't make the contract of close() method from AutoCloseable weaker, it can only add requirements. So, an abstract situation when AutoCloseable required close() to be idempotent and extended interface canceled this requirement would be just a bad design.

2. Yes, your understanding is right. It's just a contract that a programmer should take into account. Like the contract between equals() and hashCode() . You can implement it in an inconsistent way and a compiler or anything else will not flag it for you. The problem will materialize only in runtime.