RFR: 8017513: Support for closeable streams

[Paul Benedict]

Interesting thought, Henry. Given your explanation, I perhaps garner the
semantics of AutoCloseable should be loosen to equal what
MayHoldCloseableResource is. Rather than say AutoCloseable is a resource
that must be closed, simply say it's a resource that can be closed. Then
MayHoldCloseableResource can disappear.


On Thu, Jul 11, 2013 at 3:52 PM, Henry Jen <henry.jen at oracle.com> wrote:

> 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
>



-- 
Cheers,
Paul