RFR: 8017513: Support for closeable streams

[Henry Jen]

On 07/11/2013 01:22 PM, 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.
> 

I believe that the negative of 'whether a stream should be closeable or
not' is by eliminating CloseableStream vs. Stream, not the choice of
AutoCloseable.

> 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. If anything, AutoCloseable should be
> subclass of this new interface, which MIGHT hold a resource that
> requires closing. The current choice is just plainly backwards.
>

The reason to be subclass of AutoCloseable is Try-With-Resource construct.

AutoCloseable is not a fit mainly because close() method throws
Exception, and as you suggested, the "impression"(not explicit
expressed, look at other AutoCloseable where close() is not required)
that AutoCloseable means something should be closed.

While I agree your argument, I sort of thinking it's more Closeable vs
MayHoldCloseableResource, where AutoCloseable is a indicator that such
resource can be closed with TWR.

Cheers,
Henry