On 07/12/2013 01:14 AM, Zhong Yu wrote:
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?
Hi Zhong (and Roger),
Well, if @HoldsResource had RUNTIME retention, then by using:
instance.getClass(), ... clazz.getSuperclass(), getInterfaces(), ... etc.
And why
do we even care? Just call close() regardless.
I was just trying to illustrate a hypothetical code that works with
MayHoldCloseableResource contract and breaks if AutoCloseable is passed
to it. In case AutoCloseable was a subtype of MayHoldCloseableResource,
considering Liskov substitution principle, it should work: /"if S is a
//subtype <http://en.wikipedia.org/wiki/Subtype>//of T, then objects of
//type <http://en.wikipedia.org/wiki/Datatype>//T may be replaced with
objects of type S (i.e., objects of type S may be substituted for
objects of type T) without altering any of the desirable properties of
that program (correctness, task performed, etc.)"/. In reality the
decision about calling or not calling the close() is hard-coded by the
programmer, guided by static analysis tools, IDEs and so on, but that
doesn't change the reasoning.
And we can revert the parent/child relation, because the "otherwise
specified" clause is a panacea.
Could you elaborate that?
Regards, Peter
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
