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.hol...@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.hol...@oracle.com >> <mailto:david.holmes@oracle.**com <david.hol...@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....@oracle.com >> <mailto:henry....@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
