On Thu, Jul 11, 2013 at 4:08 PM, Peter Levart <peter.lev...@gmail.com> wrote: > Hi Paul, > > I think the MayHoldCloseableResource extends AutoClosable is correct and > AutoClosable extends MayHoldCloseableResource would be wrong. > > And exactly because of "Liskov": > > MayHoldCloseableResource contract says: "If you know it holds a resource, > call close(), otherwise you need not call close(), but it's not wrong to > call it anyway - you know whether it holds resource by looking at > @HoldsResource annotation" > > AutoClosable contract says: "It holds a resource, you should call close()" > > > Now imagine code that was written for the AutoClosable contract. Would it > work if you pass it an instance of MayHoldCloseableResource? Allways. > > Now imagine generic code that was written for MayHoldCloseableResource > contract and which uses the lookup of @HoldsResource at runtime to decide
How do you lookup an annotation on an _instance_ at runtime? And why do we even care? Just call close() regardless. And we can revert the parent/child relation, because the "otherwise specified" clause is a panacea. Zhong Yu > whether to call close() or not. Would it work if you pass it an instance of > AutoClosable? Never (since AutoClosable says nothing about any annotation). > > So I argue that MayHoldCloseableResource should be a subtype of AutoClosable > and not the other way around. > > (I have not said anything about whether the MayHoldCloseableResource is > actually needed or not.) > > > Regards, Peter > > > > On 07/11/2013 10: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. >> >> 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. >> >> 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> 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 >>> >>>>> 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 >>> >>> >>> >
