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