RFR: 8017513: Support for closeable streams
fweimer at redhat.com
Mon Jul 15 07:54:13 UTC 2013
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
>> the semantics of AutoCloseable indicates you have a resource that
>> 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
> > 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
More information about the core-libs-dev