RFR: 8017513: Support for closeable streams

[David Holmes]

On 12/07/2013 11:57 PM, Paul Benedict wrote:
> I see closeability as a postcondition. A subtype can't weaken it. The
> contract of AutoCloseable says its a resource that "must" be closed. Now
> MHCR says it can/should/doesn't have to be closed -- so it is backwards.

A "postcondition" of what? pre- and post-conditions go with methods. 
"closeability" is an invariant as far as I can see. Hence must be 
maintained in a substitutable subtype - which it is not no matter which 
way you try the inheritance.

David

>
> On Fri, Jul 12, 2013 at 6:22 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> 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"?
>
>
>         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.
>
>
>     No what you just said is "plainly backwards". If AutoCloseable is a
>     subtype of MHCR then you should be able to use an AC instance
>     anywhere you use a MHCR. But valid code doesn't have to close a
>     MHCR, so if you replace it with an AC which requires closing then
>     you have broken code. Hence not substitutable, hence invalid
>     inheritance relationship.
>
>     But if anything this is just another variation of the
>     Square/Rectangle inheritance fallacy. While you can define either as
>     a specialization of the other, you can always violate
>     substitutability by doing something that relies on the property that
>     gets specialized.
>
>     David
>     -----
>
>
>
>         For the above reason stated, and for the fact the interface adds
>         no new
>         functionality, it's superfluous. If the interface relationship
>         can't be
>         inverted, then chuck it -- it does nothing anyway. At the least,
>         keep the
>         annotation.
>
>         Paul
>
>
>         On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen <henry.jen at oracle.com
>         <mailto:henry.jen at oracle.com>> wrote:
>
>             On 07/11/2013 01:13 AM, Florian Weimer wrote:
>
>                 On 07/10/2013 11:30 PM, Henry Jen wrote:
>
>                     A new interface,
>                     java.util.__MayHoldCloseableResource, indicates an
>                     implementation may or may not hold a resource need
>                     to be closed.
>
>
>                 Why doesn't close() throw Exception?
>
>
>             Because there is really much a developer can do on that
>             situation. The
>             API simply make it not throw a *checked* exception.
>
>             See EG discussion on this topic,
>
>
>             http://mail.openjdk.java.net/__pipermail/lambda-libs-spec-__experts/2013-June/002081.html
>             <http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html>
>
>
>                     Annotation {@link HoldsResource} may be used to
>                     guide users/static
>                     analysis tools that a MHCR instance that definitely
>                     hold a Closeable
>                     resource.
>
>
>                 All this looks a bit odd to me.  I suppose the idea is
>                 that you don't
>                 want to give up the last reference to a closeable
>                 resource without
>                 calling close()—and not leak references which out-live
>                 the call to
>                 close().  This is definitely not a property of the type
>                 of the resource,
>                 so I don't see why the MayHoldCloseableResource
>                 interface is needed (or
>                 can confer relevant information).  The HoldsResource
>                 annotation could be
>                 useful, but based on the current documentation, it's not
>                 clear if it is
>                 actually intended to express the data flow property.
>
>
>             I would suggest you look at EG discussion on this topic. The
>             MHCR is
>             different from AutoCloseable on the chances of holding
>             critical resources.
>
>             Perhaps that suggests the javadoc is not clear enough, I
>             would like to
>             know what is important and missing.
>
>             Cheers,
>             Henry
>
>
>
>
>
>
>
>
> --
> Cheers,
> Paul