RFR: 8017513: Support for closeable streams

[Florian Weimer]

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