RFR: 8017513: Support for closeable streams

[Peter Levart]

On 07/12/2013 01:14 AM, Zhong Yu wrote:
> On Thu, Jul 11, 2013 at 4:08 PM, Peter Levart <peter.levart at 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.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
>>>>
>>>>>> 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
>>>>
>>>>
>>>>