RFR: 8017513: Support for closeable streams
David Holmes
david.holmes at oracle.com
Mon Jul 15 05:12:23 UTC 2013
On 15/07/2013 2:47 PM, Paul Benedict wrote:
> 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.
That's not a post-condition in a type substitutability sense, it is an
invariant property of the object.
David
>
>
> On Sun, Jul 14, 2013 at 10:53 PM, David Holmes <david.holmes at oracle.com
> <mailto: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>
> <mailto:david.holmes at oracle.__com
> <mailto: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>
> <mailto: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
More information about the core-libs-dev
mailing list