On Fri, Jul 12, 2013 at 6:22 AM, David Holmes <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
If the only information we have is that the object is a MHCR, we must close it. If we have other information, e.g. it's a Stream is from an ArrayList, then we may omit the close() call. The annotation @HoldsResource is meant to add extra information; particularly, *lack* of the annotation is meant to be a definitive information that close() can be omitted ! That's incredibly brittle. Zhong Yu > 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> 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 >>> >>> >>> >> >> >
