RFR: 8017513: Support for closeable streams

[roger riggs]

Hi,

Wouldn't the close() implementation be nil in most cases if there was no 
resource.
That kind of method runs very quickly and I would expect the compiler to 
inline nothing.

It would be quicker to just call close() than to engage reflection to 
determine
if it really did and then decide to call it.  Or am I missing some point 
about
generating code or in some cases not needing/wanting to close it?

Roger



On 7/11/2013 5:08 PM, Peter Levart 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 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
>>>
>>>
>>>
>