On 07/12/2013 01:22 PM, David Holmes wrote:
On 12/07/2013 6:22 AM, Paul Benedict wrote:
Paul S.'s said the "negative" of using AutoCloseable is "it is no longer
clear whether a stream should be closed or not" (6/20). That's true
because
the semantics of AutoCloseable indicates you have a resource that
requires
closing.
However, the choice to make MayHoldCloseableResource a sub-interface of
AutoClosable should be resisted. It's an inverted design. The Liskov
*substitution principle *says that sub-interfaces can't loosen the
contracts
> of their superinterface.
Not quite. It says:
- Preconditions cannot be strengthened in a subtype.
- Postconditions cannot be weakened in a subtype.
- Invariants of the supertype must be preserved in a subtype.
Question is: what kind of property is "closeability"?
In the Java type system, it's not a property of the type at all.
You should call close() on an AutoCloseable reference iff this is the
last reference to the object *and* if the close operation does not
propagate to some underlying object that outlives the reference (which
can happen with FilterInputStream, for example).
Is there really a risk that IDEs would warn about missing close() calls
in the streams framework? That seems unlikely because without method-
and object-specific annotations (which aren't available in other parts
of the platform), those diagnostics would be full of false positives.
--
Florian Weimer / Red Hat Product Security Team
