RFR: 8017513: Support for closeable streams

[Paul Benedict]

It's a post-condition to using the object. I've emphasized the "must" part
of the contract but the full contract is: "must be closed when it is no
longer needed". That's a pretty clear post-condition language that must be
true. So when you're done with the AutoCloseable type, as in the
post-condition, it must be closed. That's the expected behavior when using
this type.



On Sun, Jul 14, 2013 at 10:53 PM, David Holmes <david.holmes at oracle.com>wrote:

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


-- 
Cheers,
Paul