Menu
As far as I know, the Closeable interface was around from Java 1.5 and the AutoCloseable was introduced in Java 1.7.
What I am trying to understand is why Closeable extends AutoCloseable and not vice versa? Is this done because of backward dependency (not being able to change the Closeable interface) i.e. the need for AutoCloseable to have a wider exception than Closeable? Or is my logic just wrong and it should be that way?
360
Closeable extends IOException whereas AutoCloseable extends Exception. Closeable interface is idempotent (calling close() method more than once does not have any side effects) whereas AutoCloseable does not provide this feature. AutoCloseable was specially introduced to work with try-with-resources statements.
The close() method of an AutoCloseable object is called automatically when exiting a try -with-resources block for which the object has been declared in the resource specification header. This construction ensures prompt release, avoiding resource exhaustion exceptions and errors that may otherwise occur.
Any object that implements java. lang. AutoCloseable , which includes all objects which implement java.
This way, all the user code which implemented Closeable automatically gets to implement AutoCloseable, which allows them to automatically benefit from the try-with-resources syntax.
139
@Sotirios Delimanolis's comment has nailed it.
The Java 7 team wanted a mechanism to label objects as be auto-closeable for the "try with resources" construct. Unfortunately the API spec for the Closeable.close() method is too strict. It requires the close() method to be idempotent ... but this is not necessary in the "try with resources" use-case.
So they introduced the AutoClosable interface with a less restrictive close() semantic ... and retro-fitted Closeable as a subtype of AutoCloseable.
The other thing is that AutoCloseable.close() is declared as throwing Exception rather than IOException. This means that the AutoCloseable API is less restrictive than Closeable ... and given that it is effectively used as a callback API in try-with-resources, this makes it more flexible / more broadly applicable. (The API can be used for resources that have nothing to do with I/O, but still might throw exceptions on close.) The flip-side is that Java typing would not allow them to make such a change if the close() throws Exception method had been injected into the subtype.
The alternatives would have been:
to restrict "try with resources" to resources with an idempotent close ... which limits its usefulness, or
to retrospectively change the semantics of Closeable.close() ... which could lead to difficulties for folks porting older code to Java 7
to retrospectively change the signature of Closeable.close() ... which would break binary compatibility.
30
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
